idnits 2.17.1 draft-ietf-radius-tunnel-imp-04.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. Found some kind of copyright notice around line 872 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) 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 18 longer pages, the longest (page 2) being 61 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.) ** There are 269 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 431 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 203: '...rmitted, the NAS SHOULD NOT send an...' RFC 2119 keyword, line 206: '... described in [6]. The Client MAY then renegotiate LCP, and from that...' RFC 2119 keyword, line 211: '... and NAS MUST NOT begin NCP negoti...' RFC 2119 keyword, line 254: '..., in L2TP the tunnel server MAY choose...' RFC 2119 keyword, line 263: '...Calling-Station-Id MAY be furnished in...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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...' == (264 more instances...) -- 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 (9 October 1998) is 9330 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) -- Missing reference section? '1' on line 793 looks like a reference -- Missing reference section? '4' on line 805 looks like a reference -- Missing reference section? '3' on line 801 looks like a reference -- Missing reference section? '5' on line 808 looks like a reference -- Missing reference section? '2' on line 796 looks like a reference -- Missing reference section? '6' on line 811 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 9 October 1998 8 Implementation of 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 ftp.ietf.org (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 May 1, 1999. Please send 29 comments to the authors. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 3. Abstract 37 This document discusses implementation issues arising in the provi- 38 sioning of compulsory tunneling in dial-up networks using the L2TP 39 protocol. This provisioning can be accomplished via the integration 40 of RADIUS and tunneling protocols. Implementation issues encountered 41 with other tunneling protocols are left to separate documents. 43 4. Terminology 45 Voluntary Tunneling 46 In voluntary tunneling, a tunnel is created by the user, 47 typically via use of a tunneling client. 49 Compulsory Tunneling 50 In compulsory tunneling, a tunnel is created without any 51 action from the user and without allowing the user any 52 choice. 54 Tunnel Network Server 55 This is a server which terminates a tunnel. In L2TP termi- 56 nology, this is known as the L2TP Network Server (LNS). 58 Network Access Server 59 The Network Access Server (NAS) is the device that clients 60 contact in order to get access to the network. In L2TP ter- 61 minology, a NAS performing compulsory tunneling is referred 62 to as the L2TP Access Concentrator (LAC). 64 RADIUS authentication server 65 This is a server which provides for authentication/autho- 66 rization via the protocol described in [1]. 68 RADIUS proxy 69 In order to provide for the routing of RADIUS authentication 70 requests, a RADIUS proxy can be employed. To the NAS, the 71 RADIUS proxy appears to act as a RADIUS server, and to the 72 RADIUS server, the proxy appears to act as a RADIUS client. 73 be used to locate the tunnel endpoint when realm-based tun- 74 neling is used. 76 5. Requirements language 78 In this document, the key words "MAY", "MUST, "MUST NOT", 79 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 80 interpreted as described in [4]. 82 6. Introduction 84 Many applications of tunneling protocols involve dial-up network 85 access. Some, such as the provisioning of secure access to corporate 86 intranets via the Internet, are characterized by voluntary tunneling: 87 the tunnel is created at the request of the user for a specific pur- 88 pose. Other applications involve compulsory tunneling: the tunnel is 89 created without any action from the user and without allowing the user 90 any choice. 92 Examples of applications that might be implemented using compulsory 93 tunnels are Internet software upgrade servers, software registration 94 servers and banking services. These are all services which,without 95 compulsory tunneling, would probably be provided using dedicated net- 96 works or at least dedicated network access servers (NAS), since they 97 are characterized by the need to limit user access to specific hosts. 99 Given the existence of widespread support for compulsory tunneling, 100 however, these types of services could be accessed via any Internet 101 service provider (ISP). The most popular means of authorizing dial-up 102 network users today is through the RADIUS protocol. The use of 103 RADIUS allows the dial-up users' authorization and authentication data 104 to be maintained in a central location, rather than on each NAS. It 105 makes sense to use RADIUS to centrally administer compulsory tun- 106 neling, since RADIUS is widely deployed and was designed to 107 carry this type of information. New RADIUS attributes are needed to 108 carry the tunneling information from the RADIUS server to the NAS. 109 Those attributes are defined in [3]. 111 6.1. Advantanges of RADIUS-based compulsory tunneling 113 Current proposals for routing of tunnel requests include static tun- 114 neling, where all users are automatically tunneled to a given end- 115 point, and realm-based tunneling, where the tunnel endpoint is deter- 116 mined from the realm portion of the userID. User-based tunneling as 117 provided by integration of RADIUS and tunnel protocols offers signifi- 118 cant advantages over both of these approaches. 120 Static tunneling requires dedication of a NAS device to the purpose. 121 In the case of an ISP, this is undesirable because it requires them to 122 dedicate a NAS to tunneling service for a given customer, rather than 123 allowing them to use existing NASes deployed in the field. As a result 124 static tunneling is likely to be costly for deployment of a global 125 service. 127 Realm-based tunneling assumes that all users within a given realm wish 128 to be treated the same way. This limits flexibility in account manage- 129 ment. For example, BIGCO may desire to provide Janet with an account 130 that allows access to both the Internet and the intranet, with Janet's 131 intranet access provided by a tunnel server located in the engineering 132 department. However BIGCO may desire to provide Fred with an account 133 that provides only access to the intranet, with Fred's intranet access 134 provided by a tunnel network server located in the sales department. 135 Such a situation cannot be accommodated with realm-based tunneling, 136 but can be accomodated via user-based tunneling as enabled by the 137 attributes defined in [3]. 139 7. Authentication alternatives 141 RADIUS-based compulsory tunneling can support both single authentica- 142 tion, where the user is authenticated at the NAS or tunnel server, or 143 dual authentication, where the user is authenticated at both the NAS 144 and the tunnel server. When single authentication is supported, a 145 variety of modes are possible, including telephone-number based 146 authentication. When dual-authentication is used, a number of modes 147 are available, including dual CHAP authentications; CHAP/EAP authenti- 148 cation; CHAP/PAP(token) authentication; and EAP/EAP authentication, 149 using the same EAP type for both authentications. EAP is described in 150 [5]. 152 The alternatives are described in more detail below. 154 7.1. Single authentication 156 Single authentication alternatives include: 158 NAS authentication 159 NAS authentication with RADIUS reply forwarding 160 Tunnel server authentication 162 7.1.1. NAS authentication 164 With this approach, authentication and authorization (including tun- 165 neling information) occurs once, at the NAS. The advantages of this 166 approach are that it disallows network access for unauthorized NAS 167 users, and permits accounting to done at the NAS. Disadvantages are 168 that it requires that the tunnel server trust the NAS, since no user 169 authentication occurs at the tunnel server. Due to the lack of user 170 authentication, accounting cannot take place at the tunnel server with 171 strong assurance that the correct party is being billed. 173 NAS-only authentication is most typically employed along with LCP for- 174 warding and tunnel authentication, both of which are supported in 175 L2TP, described in [2]. Thus, the tunnel server can be set up to 176 accept all calls occurring within authenticated tunnels, without 177 requiring PPP authentication. However, this approach is not compati- 178 ble with roaming, since the tunnel server will typically only be set 179 up to accept tunnels from a restricted set of NASes. A typical initia- 180 tion sequence looks like this: 182 Client and NAS: Call Connected 183 Client and NAS: PPP LCP negotiation 184 Client and NAS: PPP authentication 185 NAS to RADIUS Server: RADIUS Access-request 186 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 187 NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding 188 Tunnel Server to NAS: L2TP Incoming-Call-Reply 189 NAS to Tunnel Server: L2TP Incoming-Call-Connected 190 Client and Tunnel Server: NCP negotiation 192 The process begins with an incoming call to the NAS, and the PPP LCP 193 negotiation between the client and the NAS. In order to authenticate 194 the client, the NAS will send a RADIUS Access-Request to the RADIUS 195 server and will receive a RADIUS Access-Accept including tunnel 196 attributes, or an Access-Reject. 198 In the case where an L2TP tunnel is indicated, the NAS will now bring 199 up a control connection if none existed before, and the NAS and tunnel 200 server will bring up the call. At this point, data will begin to flow 201 through the tunnel. The NAS will typically employ LCP forwarding, 202 although it is also possible for the tunnel server to renegotiate LCP. 203 If LCP renegotiation is to be permitted, the NAS SHOULD NOT send an 204 LCP CONFACK completing LCP negotiation. Rather than sending an LCP 205 CONFACK, the NAS will instead send an LCP Configure-Request packet, 206 described in [6]. The Client MAY then renegotiate LCP, and from that 207 point forward, all PPP packets originated from the client will be 208 encapsulated and sent to the tunnel server. 210 Since address assignment will occur at the tunnel server, the client 211 and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will 212 occur between the client and the tunnel server. 214 7.1.2. NAS authentication with RADIUS reply forwarding 216 With this approach, authentication and authorization occurs once at 217 the NAS and the RADIUS reply is forwarded to the tunnel server. This 218 approach disallows network access for unauthorized NAS users; does not 219 require trust between the NAS and tunnel server; and allows for 220 accounting to be done at both ends of the tunnel. However, it also 221 requires that both ends share the same secret with the RADIUS server, 222 since that is the only way that the tunnel server can check the RADIUS 223 Access-Reply. 225 In this approach, the tunnel server will share secrets with all the 226 NASes and associated RADIUS servers, and there is no provision for LCP 227 renegotiation by the tunnel server. Also, the tunnel server will need 228 to know how to handle and verify RADIUS Access-Accept messages. 230 While this scheme can be workable if the reply comes directly from a 231 RADIUS server, it would become unmanageable if a RADIUS proxy is 232 involved, since the reply would be authenticated using the secret 233 shared by the client and proxy, rather than the RADIUS server. As a 234 result, this scheme is impractical. 236 7.1.3. Tunnel server authentication 238 In this scheme, authentication and authorization occurs once at the 239 tunnel server. This requires that the NAS determine that the user 240 needs to be tunneled (through RADIUS or NAS configuration). Where 241 RADIUS is used, the determination can be made using one of the follow- 242 ing methods: 244 Telephone-number based authentication 245 UserID 247 7.1.3.1. Telephone-number based authentication 249 Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, 250 authorization and subsequent tunnel attributes can be based on the 251 phone number originating the call, or the number being called. This 252 allows the RADIUS server to authorize users based on the calling phone 253 number or to provide tunnel attributes based on the Calling-Station-Id 254 or Called-Station-Id. Similarly, in L2TP the tunnel server MAY choose 255 to reject or accept the call based on the Dialed Number and Dialing 256 Number included in the L2TP Incoming-Call-Request packet sent by the 257 NAS. Accounting can also take place based on the Calling-Station-Id 258 and Called-Station-Id. 260 RADIUS as defined in [1] requires that an Access-Request packet con- 261 tain a User-Name attribute as well as either a CHAP-Password or User- 262 Password attribute, which must be non-empty. To satisfy this require- 263 ment the Called-Station-Id or Calling-Station-Id MAY be furnished in 264 the User-Name attribute and a dummy value MAY be used in the User- 265 Password or CHAP-Password attribute. 267 In the case of telephone-number based authentication, a typical initi- 268 ation sequence looks like this: 270 Client and NS: Call Connected 271 NAS to RADIUS Server: RADIUS Access-request 272 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 273 NAS to Tunnel Server: L2TP Incoming-Call-Request 274 Tunnel Server to NAS: L2TP Incoming-Call-Reply 275 NAS to Tunnel Server: L2TP Incoming-Call-Connected 276 Client and Tunnel Server: PPP LCP negotiation 277 Client and Tunnel Server: PPP authentication 278 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 279 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 280 Client and Tunnel Server: NCP negotiation 282 The process begins with an incoming call to the NAS. If configured for 283 telephone-number based authentication, the NAS sends a RADIUS Access- 284 Request containing the Calling-Station-Id and the Called-Station-Id 285 attributes. The RADIUS server will then respond with a RADIUS Access- 286 Accept or Access-Reject. 288 The NAS MUST NOT begin PPP authentication before bringing up the tun- 289 nel. If timing permits, the NAS MAY bring up the tunnel prior to 290 beginning LCP negotiation with the peer. If this is done, then LCP 291 will not need to be renegotiated between the peer and tunnel server, 292 nor will LCP forwarding need to be employed. 294 If the initial telephone-number based authentication is unsuccessful, 295 the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS 296 MUST send an LCP-Terminate and disconnect the user. 298 In the case where tunnel attributes are included in the RADIUS Access- 299 Accept, and an L2TP tunnel is indicated, the NAS will now bring up a 300 control connection if none existed before. This is accomplished by 301 sending an L2TP Start-Control-Connection-Request message to the tunnel 302 server. The tunnel server will then reply with an L2TP Start-Control- 303 Connection-Reply. If this message indicates an error, or if the con- 304 trol connection is terminated at any future time, then the NAS MUST 305 send an LCP-Terminate and disconnect the user. 307 The NAS will then send an L2TP Incoming-Call-Request message to the 308 tunnel server. Among other things, this message will contain the Call 309 Serial Number, which along with the NAS-IP-Address and Tunnel-Server- 310 Endpoint is used to uniquely identify the call. The tunnel server will 311 reply with an L2TP Incoming-Call-Reply message. If this message indi- 312 cates an error, then the NAS MUST send an LCP-Terminate and disconnect 313 the user. If no error is indicated, the NAS then replies with an L2TP 314 Incoming-Call-Connected message. 316 At this point, data can begin to flow through the tunnel. If LCP nego- 317 tiation had been begun between the NAS and the client, then LCP for- 318 warding may be employed, or the client and tunnel server will now 319 renegotiate LCP and begin PPP authentication. Otherwise, the client 320 and tunnel server will negotiate LCP for the first time, and then move 321 on to PPP authentication. 323 If a renegotiation is required, at the time that the renegotiation 324 begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP 325 negotiation, and the client and NAS MUST NOT have begun NCP negotia- 326 tion. Rather than sending an LCP CONFACK, the NAS will instead send an 327 LCP Configure-Request Packet, described in [6]. The Client MAY then 328 renegotiate LCP, and from that point forward, all PPP packets origi- 329 nated from the client will be encapsulated and sent to the tunnel 330 server. When LCP re-negotiation has been concluded, the NCP phase 331 will begin, and the tunnel server will assign an address to the 332 client. 334 If L2TP is being used as the tunnel protocol, and LCP renegotiation is 335 required, the NAS MAY in its initial setup notification include a copy 336 of the LCP CONFACKs sent in each direction which completed LCP negoti- 337 ation. The tunnel server MAY then use this information to avoid an 338 additional LCP negotiation. With L2TP, the initial setup notification 339 can also include the authentication information required to allow the 340 tunnel server to authenticate the user and decide to accept or decline 341 the connection. However, in telephone-number based authentication, PPP 342 authentication MUST NOT occur prior to the NAS bringing up the tunnel. 343 As a result, L2TP authentication forwarding MUST NOT be employed. 345 In performing the PPP authentication, the tunnel server can access its 346 own user database, or alternatively can send a RADIUS Access-Request. 347 The latter approach is useful in cases where authentication forwarding 348 is enabled, such as with roaming or shared use networks. In this case, 349 the RADIUS and tunnel servers are under the same administration and 350 are typically located close together, possibly on the same LAN. 351 Therefore having the tunnel server act as a RADIUS client provides for 352 unified user administration. Note that the tunnel server's RADIUS 353 Access-Request is typically sent directly to the local RADIUS server 354 rather than being forwarded via a proxy. 356 The interactions involved in initiation of a compulsory tunnel with 357 telephone-number based authentication are summarized below. In order 358 to simplify the diagram that follows, we have left out the client. 359 However, it is understood that the client participates via PPP negoti- 360 ation, authentication and subsequent data interchange with the Tunnel 361 Server. 363 INITIATION SEQUENCE 365 NAS Tunnel Server RADIUS Server 366 --- ------------- ------------- 367 Call connected 368 Send RADIUS 369 Access-Request 370 with Called-Station-Id, 371 and/or Calling-Station-Id 372 LCP starts 373 IF authentication 374 succeeds 375 Send ACK 376 ELSE Send NAK 377 IF NAK DISCONNECT 378 ELSE 379 IF no control 380 connection exists 381 Send 382 Start-Control-Connection-Request 383 to Tunnel Server 384 Send 385 Start-Control-Connection-Reply 386 to NAS 387 ENDIF 389 Send 390 Incoming-Call-Request 391 message to Tunnel Server 392 Send Incoming-Call-Reply 393 to NAS 394 Send 395 Incoming-Call-Connected 396 message to Tunnel Server 398 Send data through the tunnel 399 Re-negotiate LCP, 400 authenticate user, 401 bring up IPCP, 402 start accounting 404 7.1.3.2. User-Name 406 Since authentication will occur only at the tunnel-server, tunnel ini- 407 tiation must occur prior to user authentication at the NAS. As a 408 result, this scheme typically uses either the domain portion of the 409 userID or attribute-specific processing on the RADIUS server. Since 410 the user identity is never verified by the NAS, either the tunnel 411 server owner must be willing to be billed for all incoming calls, or 412 other information such as the Calling-Station-Id must be used to ver- 413 ify the user's identity for accounting purposes. 415 In attribute-specific processing RADIUS may be employed and an 416 attribute is used to signal tunnel initiation. For example, tunnel 417 attributes can be sent back if the User-Password attribute contains a 418 dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID 419 beginning with a special character ('*') could be used to indicate the 420 need to initiate a tunnel. When attribute-specific processing is 421 used, the tunnel server may need to renegotiate LCP. 423 Another solution involves using the domain portion of the userID; all 424 users in domain X would be tunneled to address Y. This proposal sup- 425 ports compulsory tunneling, but does not provide for user-based tun- 426 neling. 428 In order for the NAS to start accounting on the connection, it would 429 need to use the identity claimed by the user in authenticating to the 430 tunnel server, since it did not verify the identity via RADIUS. How- 431 ever, in order for that to be of any use in accounting, the tunnel 432 endpoint needs to have an account relationship with the NAS owner. 433 Thus even if a user has an account with the NAS owner, they cannot use 434 this account for tunneling unless the tunnel endpoint also has a busi- 435 ness relationship with the NAS owner. Thus this approach is incompati- 436 ble with roaming. 438 A typical initiation sequence involving use of the domain portion of 439 the userID looks like this: 441 Client and NAS: Call Connected 442 Client and NAS: PPP LCP negotiation 443 Client and NAS: Authentication 444 NAS to Tunnel Server: L2TP Incoming-Call-Request 445 Tunnel Server to NAS: L2TP Incoming-Call-Reply 446 NAS to Tunnel Server: L2TP Incoming-Call-Connected 447 Client and Tunnel Server: PPP LCP re-negotiation 448 Client and Tunnel Server: PPP authentication 449 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 450 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 451 Client and Tunnel Server: NCP negotiation 453 The process begins with an incoming call to the NAS, and the PPP LCP 454 negotiation between the Client and NAS. The authentication process 455 will then begin and based on the domain portion of the userID, the NAS 456 will now bring up a control connection if none existed before, and the 457 NAS and tunnel server will bring up the call. At this point, data MAY 458 begin to flow through the tunnel. The client and tunnel server MAY 459 now renegotiate LCP and will complete PPP authentication. 461 At the time that the renegotiation begins, the NAS SHOULD NOT have 462 sent an LCP CONFACK completing LCP negotiation, and the client and NAS 463 MUST NOT have begun NCP negotiation. Rather than sending an LCP CON- 464 FACK, the NAS will instead send an LCP Configure-Request packet, 465 described in [6]. The Client MAY then renegotiate LCP, and from that 466 point forward, all PPP packets originated from the client will be 467 encapsulated and sent to the tunnel server. In single authentication 468 compulsory tunneling, L2TP authentication forwarding MUST NOT be 469 employed. When LCP re-negotiation has been concluded, the NCP phase 470 will begin, and the tunnel server will assign an address to the 471 client. 473 In performing the PPP authentication, the tunnel server can access its 474 own user database, or it MAY send a RADIUS Access-Request. After the 475 tunnel has been brought up, the NAS and tunnel server can start 476 accounting. 478 The interactions are summarized below. 480 INITIATION SEQUENCE 482 NAS Tunnel Server RADIUS Server 483 --- ------------- ------------- 484 Call accepted 485 LCP starts 486 Authentication 487 phase starts 488 IF no control 489 connection exists 490 Send 491 Start-Control-Connection-Request 492 to Tunnel Server 493 ENDIF 494 IF no control 495 connection exists 496 Send 497 Start-Control-Connection-Reply 498 to NAS 499 ENDIF 501 Send 502 Incoming-Call-Request 503 message to Tunnel Server 504 Send Incoming-Call-Reply 505 to NAS 506 Send 507 Incoming-Call-Connected 508 message to Tunnel Server 510 Send data through the tunnel 511 Re-negotiate LCP, 512 authenticate user, 513 bring up IPCP, 514 start accounting 516 7.2. Dual authentication 518 In this scheme, authentication occurs both at the NAS and the tunnel 519 server. This requires the dial-up client to handle dual 520 authentication, with attendant LCP re-negotiations. In order to allow 521 the NAS and tunnel network server to authenticate against the same 522 database, this requires RADIUS client capability on the tunnel network 523 server, and possibly a RADIUS proxy on the NAS end. 525 Advantages of dual authentication include support for authentication 526 and accounting at both ends of the tunnel; use of a single 527 userID/password pair via implementation of RADIUS on the tunnel net- 528 work server; no requirement for telephone-number based authentication, 529 or attribute-specific processing on the RADIUS server. 531 Dual authentication allows for accounting records to be generated on 532 both the NAS and tunnel server ends, making auditing possible. Also 533 the tunnel endpoint does not need to have an account relationship with 534 the NAS owner, making this approach compatible with roaming. 536 A disadvantage of dual authentication is that unless LCP forwarding is 537 used, LCP will need to be renegotiated; some clients do not support it 538 at all, and others only support only a subset of the dual authentica- 539 tion combinations. Feasible combinations include PAP/PAP(token), 540 PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and 541 EAP/EAP. EAP is described in [5]. 543 In the case of a dual authentication, a typical initiation sequence 544 looks like this: 546 Client and NAS: PPP LCP negotiation 547 Client and NAS: PPP authentication 548 NAS to RADIUS Server: RADIUS Access-request 549 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 550 NAS to Tunnel Server: L2TP Incoming-Call-Request 551 Tunnel Server to NAS: L2TP Incoming-Call-Reply 552 NAS to Tunnel Server: L2TP Incoming-Call-Connected 553 Client and Tunnel Server: PPP LCP re-negotiation (optional) 554 Client and Tunnel Server: PPP authentication 555 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 556 RADIUS server to Tunel Server: RADIUS Access-Accept/Access-Reject 557 Client and Tunnel Server: NCP negotiation 559 The process begins with an incoming call to the NAS. The client and 560 NAS then begin LCP negotiation. Subsequently the PPP authentication 561 phase starts, and the NAS sends a RADIUS Access-Request message to the 562 RADIUS server. If the authentication is successful, the RADIUS server 563 responds with a RADIUS Access-Accept containing tunnel attributes. 565 In the case where an L2TP tunnel is indicated, the NAS will now bring 566 up a control connection if none existed before, and the NAS and tunnel 567 server will bring up the call. At this point, data MAY begin to flow 568 through the tunnel. The client and tunnel server MAY now renegotiate 569 LCP and go through another round of PPP authentication. At the time 570 that this renegotiation begins, the NAS SHOULD NOT have sent an LCP 571 CONFACK completing LCP negotiation, and the client and NAS MUST NOT 572 have begun NCP negotiation. Rather than sending an LCP CONFACK, the 573 NAS will instead send an LCP Configure-Request packet, described in 575 [6]. The Client MAY then renegotiate LCP, and from that point for- 576 ward, all PPP packets originated from the client will be encapsulated 577 and sent to the tunnel server. When LCP re-negotiation has been con- 578 cluded, the NCP phase will begin, and the tunnel server will assign an 579 address to the client. 581 If L2TP is being used as the tunnel protocol, the NAS MAY in its ini- 582 tial setup notification include a copy of the LCP CONFACKs sent in 583 each direction which completed LCP negotiation. The tunnel server MAY 584 then use this information to avoid an additional LCP negotiation. With 585 L2TP, the initial setup notification can also include the authentica- 586 tion information required to allow the tunnel server to authenticate 587 the user and decide to accept or decline the connection. However, this 588 facility creates a vulnerability to replay attacks, and can create 589 problems in the case where the NAS and tunnel server authenticate 590 against different RADIUS servers. As a result, where user-based tun- 591 neling via RADIUS is implemented, L2TP authentication forwarding 592 SHOULD NOT be employed. 594 In performing the PPP authentication, the tunnel server can access its 595 own user database, or it MAY send a RADIUS Access-Request. After the 596 tunnel has been brought up, the NAS and tunnel server can start 597 accounting. 599 The interactions involved in initiation of a compulsory tunnel with 600 dual authentication are summarized below. 602 INITIATION SEQUENCE 604 NAS Tunnel Server RADIUS Server 605 --- ------------- ------------- 606 Call accepted 607 LCP starts 608 PPP authentication 609 phase starts 610 Send RADIUS 611 Access-Request 612 with username and 613 authentication data 614 IF authentication 615 succeeds 616 Send ACK 617 ELSE Send NAK 618 IF NAK DISCONNECT 619 ELSE 620 IF no control 621 connection exists 622 Send 623 Start-Control-Connection-Request 624 to Tunnel Server 625 Send 626 Start-Control-Conection-Reply 627 to NAS 629 ENDIF 631 Send 632 Incoming-Call-Request 633 message to Tunnel Server 634 Send Incoming-Call-Reply 635 to NAS 636 Send 637 Incoming-Call-Connected 638 message to Tunnel Server 640 Send data through the tunnel 641 Re-negotiate LCP, 642 authenticate user, 643 bring up IPCP, 644 start accounting 645 ENDIF 647 8. Termination sequence 649 The tear down of a compulsory tunnel involves an interaction between 650 the client, NAS and Tunnel Server. This interaction is virtually iden- 651 tical regardless of whether telephone-number based authentication, 652 single authentication, or dual authentication is being used. In any 653 of the cases, the following events occur: 655 Tunnel Server to NAS: L2TP Call-Clear-Request (optional) 656 NAS to Tunnel Server: L2TP Call-Disconnect-Notify 658 Tunnel termination can occur due to a client request (PPP termina- 659 tion), a tunnel server request (Call-Clear-Request), or a line problem 660 (call disconnect). 662 In the case of a client-requested termination, the tunnel server MUST 663 terminate the PPP session. The tunnel server MUST subsequently send a 664 Call-Clear-Request to the NAS. The NAS MUST then send a Call-Discon- 665 nect-Notify message to the tunnel server, and will disconnect the 666 call. 668 The NAS MUST also respond with a Call-Disconnect-Notify message and 669 disconnection if it receives a Call-Clear-Request from the tunnel 670 server without a client-requested termination. 672 In the case of a line problem or user hangup, the NAS MUST send a 673 Call-Disconnect-Notify to the tunnel server. Both sides will then tear 674 down the call. 676 The interactions involved in termination of a compulsory tunnel are 677 summarized below. In order to simplify the diagram that follows, we 678 have left out the client. However, it is understood that the client 679 MAY participate via PPP termination and disconnection. 681 TERMINATION SEQUENCE 683 NAS Tunnel Server RADIUS Server 684 --- ------------- ------------- 685 IF user disconnected 686 send 687 Call-Disconnect-Notify 688 message to tunnel server 689 Tear down the call 690 stop accounting 691 ELSE IF client requests 692 termination 693 send 694 Call-Clear-Request 695 to the NAS 696 Send 697 Call-Disconnect-Notify 698 message to tunnel server 699 Disconnect the user 700 Tear down the call 701 stop accounting 702 ENDIF 704 9. Use of distinct RADIUS servers 706 In the case that the NAS and the tunnel server are using distinct 707 RADIUS servers, some interesting cases can arise in the provisioning 708 of compulsory tunnels. 710 9.1. Distinct userIDs 712 If distinct RADIUS servers are being used, it is likely that distinct 713 userID/password pairs will be required to complete the RADIUS and tun- 714 nel authentications. One pair will be used in the initial PPP authen- 715 tication with the NAS, and the second pair will be used for authenti- 716 cation at the tunnel server. 718 This has implications if the NAS attempts to forward authentication 719 information to the tunnel server in the initial setup notification. 720 Since the userID/password pair used for tunnel authentication is dif- 721 ferent from that used to authenticate against the NAS, forwarding 722 authentication information in this manner will cause the tunnel 723 authentication to fail. As a result, where user-based tunneling via 724 RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be 725 employed. 727 In order to provide maximum ease of use in the case where the 728 userID/password pairs are identical, tunnel clients typically attempt 729 authentication with the same userID/password pair as was used in the 730 initial PPP negotiation. Only after this fails do they prompt the user 731 for the second pair. Rather than putting up an error message indicat- 732 ing an authentication failure, it is preferable to present a dialog 733 requesting the tunnel userID/password combination. 735 A similar issue arises when extended authentication methods are being 736 used, as is enabled by EAP, described in [5]. In particular, when one- 737 time passwords or cryptographic calculators are being used, different 738 passwords will be used for the first and second authentications. Thus 739 the user will need to be prompted to enter the second password. 741 9.2. Multilink PPP issues 743 It is possible for the two RADIUS servers to return different Port- 744 Limit attributes. For example, it is conceivable that the NAS RADIUS 745 server will only grant use of a single channel, while the tunnel 746 RADIUS server will grant more than one channel. In this case, the cor- 747 rect behavior is for the tunnel client to open a connection to another 748 NAS in order to bring up a multilink bundle on the tunnel server. The 749 client MUST NOT indicate to the NAS that this additional link is being 750 brought up as part of a multilink bundle; this will only be indicated 751 in the subsequent negotiation with the tunnel server. 753 It is also conceivable that the NAS RADIUS server will allow the 754 client to bring up multiple channels, but that the tunnel RADIUS 755 server will allow fewer channels than the NAS RADIUS server. In this 756 case, the client should terminate use of the excess channels. 758 10. UserID Issues 760 In the provisioning of roaming and shared use networks, one of the 761 requirements is to be able to route the authentication request to the 762 user's home RADIUS server. This authentication routing is accomplished 763 based on the userID submitted by the user to the NAS in the initial 764 PPP authentication. The userID is subsequently relayed by the NAS to 765 the RADIUS server in the User-Name attribute, as part of the RADIUS 766 Access-Request. 768 Similarly, [2] refers to use of the userID in determining the tunnel 769 endpoint, although it does not provide guidelines for how RADIUS or 770 tunnel routing is to be accomplished. Thus the possibility of con- 771 flicting interpretations exists. 773 The use of RADIUS in provisioning of compulsory tunneling relieves the 774 userID from having to do double duty. Rather than being used both for 775 routing of the RADIUS authentication/authorization request as well for 776 determination of the tunnel endpoint, the userID is now used solely 777 for routing of RADIUS authentication/authorization requests. Tunnel 778 attributes returned in the RADIUS Access-Response are then used to 779 determine the tunnel endpoint. 781 Since the framework described in this document allows both ISPs and 782 tunnel users to authenticate users as well as to account for resources 783 consumed by them, and provides for maintenance of two distinct 784 userID/password pairs, this scheme provides a high degree of 785 flexibility. Where RADIUS proxies and tunneling are employed, it is 786 possible to allow the user to authenticate with a single userID/pass- 787 word pair at both the NAS and the tunnel endpoint. This is accom- 788 plished by routing the NAS RADIUS Access-Request to the same RADIUS 789 server used by the tunnel server. 791 11. References 793 [1] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen- 794 tication Dial In User Service (RADIUS)", RFC 2138, April 1997. 796 [2] A. Valencia, K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, W. 797 Townsley, J. Taarud, G. Pall, B. Palter, W. Verthein. "Layer Two Tun- 798 neling Protocol L2TP." Internet draft (work in progress), draft-ietf- 799 pppext-l2tp-11.txt, September 1998. 801 [3] Zorn, G., Leifer, D., Rubens, A., and J. Shriver, "RADIUS 802 Attributes for Tunnel Protocol Support", Internet draft (work in 803 progress), draft-ietf-radius-tunnel-auth-06.txt, September 1998. 805 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 806 Levels", BCP 14, RFC 2119, March 1997. 808 [5] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 809 (EAP)", RFC 2284, March 1998. 811 [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, 812 RFC 1661, July 1994. 814 12. Security considerations 816 Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS 817 server may be processed by one or more proxies prior to being received 818 by the NAS. In order to ensure that tunnel attributes arrive without 819 modification, intermediate RADIUS proxies forwarding the Access-Reply 820 MUST NOT modify tunnel attributes. If the RADIUS proxy does not sup- 821 port tunnel attributes, then it MUST send an Access-Reject to the NAS. 822 This is necessary to ensure that the user is only granted access if 823 the services requested by the RADIUS server can be provided. 825 Since RADIUS tunnel attributes are used for compulsory tunneling, 826 address assignment is handled by the tunnel server rather than the 827 NAS. As a result, if tunnel attributes are present, the NAS MUST 828 ignore any address assignment attributes sent by the RADIUS server. In 829 addition, the NAS and client MUST NOT begin NCP negotiation, since 830 this could create a time window in which the client will be capable of 831 sending packets to the transport network, which is not permitted in 832 compulsory tunneling. 834 13. Acknowledgements 836 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions 837 of this problem space, and to Allan Rubens of Ascend and Bertrand 838 Buclin of AT&T Labs Europe for his comments on this document. 840 14. Chair's Address 842 The RADIUS Working Group can be contacted via the current chair: 844 Carl Rigney 845 Livingston Enterprises 846 4464 Willow Road 847 Pleasanton, California 94588 849 Phone: +1 510-426-0770 850 E-Mail: cdr@livingston.com 852 15. Authors' Addresses 854 Bernard Aboba 855 Microsoft Corporation 856 One Microsoft Way 857 Redmond, WA 98052 859 Phone: +1 425-936-6605 860 EMail: bernarda@microsoft.com 862 Glen Zorn 863 Microsoft Corporation 864 One Microsoft Way 865 Redmond, WA 98052 867 Phone: +1 425-703-1559 868 EMail: glennz@microsoft.com 870 16. Full Copyright Statement 872 Copyright (C) The Internet Society (1997). All Rights Reserved. 873 This document and translations of it may be copied and furnished to 874 others, and derivative works that comment on or otherwise explain it 875 or assist in its implmentation may be prepared, copied, published and 876 distributed, in whole or in part, without restriction of any kind, 877 provided that the above copyright notice and this paragraph are 878 included on all such copies and derivative works. However, this docu- 879 ment itself may not be modified in any way, such as by removing the 880 copyright notice or references to the Internet Society or other Inter- 881 net organizations, except as needed for the purpose of developing 882 Internet standards in which case the procedures for copyrights defined 883 in the Internet Standards process must be followed, or as required to 884 translate it into languages other than English. The limited 885 permissions granted above are perpetual and will not be revoked by the 886 Internet Society or its successors or assigns. This document and the 887 information contained herein is provided on an "AS IS" basis and THE 888 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 889 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 890 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 891 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 892 PARTICULAR PURPOSE." 894 17. Expiration Date 896 This memo is filed as , and 897 expires May 1, 1999. n