idnits 2.17.1 draft-ietf-radius-tunnel-imp-05.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 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 LC...' RFC 2119 keyword, line 206: '...[6]. The Client MAY then renegotiate LCP, and from that point forward,...' RFC 2119 keyword, line 211: '...NAS MUST NOT begin NCP negotiation. In...' RFC 2119 keyword, line 252: '...the tunnel server MAY choose to reject...' RFC 2119 keyword, line 261: '...lling-Station-Id MAY be furnished in t...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 86 has weird spacing: '...e, such as th...' == Line 92 has weird spacing: '...xamples of a...' == Line 94 has weird spacing: '...servers and ...' == Line 96 has weird spacing: '...etworks or a...' == Line 100 has weird spacing: '...Given the ex...' == (7 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 (20 August 1999) is 9014 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 782 looks like a reference -- Missing reference section? '4' on line 795 looks like a reference -- Missing reference section? '3' on line 790 looks like a reference -- Missing reference section? '5' on line 798 looks like a reference -- Missing reference section? '2' on line 786 looks like a reference -- Missing reference section? '6' on line 801 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RADIUS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Standards Track Glen Zorn 4 Microsoft 5 20 August 1999 6 Expires: March 1, 2000 8 Implementation of L2TP Compulsory Tunneling via RADIUS 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 3. Abstract 38 This document discusses implementation issues arising in the 39 provisioning of compulsory tunneling in dial-up networks using the L2TP 40 protocol. This provisioning can be accomplished via the integration of 41 RADIUS and tunneling protocols. Implementation issues encountered with 42 other tunneling protocols are left to separate documents. 44 4. Terminology 46 Voluntary Tunneling 47 In voluntary tunneling, a tunnel is created by the user, 48 typically via use of a tunneling client. 50 Compulsory Tunneling 51 In compulsory tunneling, a tunnel is created without any 52 action from the user and without allowing the user any choice. 54 Tunnel Network Server 55 This is a server which terminates a tunnel. In L2TP 56 terminology, 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 61 terminology, 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 66 authentication/authorization via the protocol described in 67 [1]. 69 RADIUS proxy 70 In order to provide for the routing of RADIUS authentication 71 requests, a RADIUS proxy can be employed. To the NAS, the 72 RADIUS proxy appears to act as a RADIUS server, and to the 73 RADIUS server, he proxy appears to act as a RADIUS client. be 74 used to locate the tunnel endpoint when realm-based tunneling 75 is used. 77 5. Requirements language 79 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 80 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 81 described in [4]. 83 6. Introduction 85 Many applications of tunneling protocols involve dial-up network access. 86 Some, such as the provisioning of secure access to corporate intranets 87 via the Internet, are characterized by voluntary tunneling: the tunnel 88 is created at the request of the user for a specific purpose. Other 89 applications involve compulsory tunneling: the tunnel is created without 90 any action from the user and without allowing the user 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 96 networks or at least dedicated network access servers (NAS), since 97 they are characterized by the need to limit user access to specific 98 hosts. 100 Given the existence of widespread support for compulsory tunneling, 101 however, these types of services could be accessed via any Internet 102 service provider (ISP). The most popular means of authorizing dial-up 103 network users today is through the RADIUS protocol. The use of RADIUS 104 allows the dial-up users' authorization and authentication data to be 105 maintained in a central location, rather than on each NAS. It makes 106 sense to use RADIUS to centrally administer compulsory tunneling, 107 since RADIUS is widely deployed and was designed to carry this 108 type of information. New RADIUS attributes are needed to carry the 109 tunneling information from the RADIUS server to the NAS. Those 110 attributes are defined in [3]. 112 6.1. Advantanges of RADIUS-based compulsory tunneling 114 Current proposals for routing of tunnel requests include static 115 tunneling, where all users are automatically tunneled to a given 116 endpoint, and realm-based tunneling, where the tunnel endpoint is 117 determined from the realm portion of the userID. User-based tunneling as 118 provided by integration of RADIUS and tunnel protocols offers 119 significant advantages over both of these approaches. 121 Static tunneling requires dedication of a NAS device to the purpose. In 122 the case of an ISP, this is undesirable because it requires them to 123 dedicate a NAS to tunneling service for a given customer, rather than 124 allowing them to use existing NASes deployed in the field. As a result 125 static tunneling is likely to be costly for deployment of a global 126 service. 128 Realm-based tunneling assumes that all users within a given realm wish 129 to be treated the same way. This limits flexibility in account 130 management. For example, BIGCO may desire to provide Janet with an 131 account that allows access to both the Internt and the intranet, with 132 Janet's intranet access provided by a tunnel server located in the 133 engineering department. However BIGCO may desire to provide Fred with an 134 account that provides only access to the intranet, with Fred's intranet 135 access provided by a tunnel network server located in the sales 136 department. Such a situation cannot be accommodated with realm-based 137 tunneling, but can be accomodated via user-based tunneling as enabled by 138 the attributes defined in [3]. 140 7. Authentication alternatives 142 RADIUS-based compulsory tunneling can support both single 143 authentication, where the user is authenticated at the NAS or tunnel 144 server, or dual authentication, where the user is authenticated at both 145 the NAS and the tunnel server. When single authentication is supported, 146 a variety of modes are possible, including telephone-number based 147 authentication. When dual-authentication is used, a number of modes are 148 available, including dual CHAP authentications; CHAP/EAP authentication; 149 CHAP/PAP(token) authentication; and EAP/EAP authentication, using the 150 same EAP type for both authentications. EAP is described in [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 165 tunneling 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 174 forwarding and tunnel authentication, both of which are supported in 175 L2TP, described in [2]. Thus, the tunnel server can be set up to accept 176 all calls occurring within authenticated tunnels, without requiring PPP 177 authentication. However, this approach is not compatible with roaming, 178 since the tunnel server will typically only be set up to accept tunnels 179 from a restricted set of NASes. A typical initiation sequence looks like 180 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 the 194 client, the NAS will send a RADIUS Access-Request to the RADIUS server 195 and will receive a RADIUS Access-Accept including tunnel attributes, or 196 an Access-Reject. 198 In the case where an L2TP tunnel is indicated, the NAS will now bring up 199 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 LCP 204 CONFACK completing LCP negotiation. Rather than sending an LCP CONFACK, 205 the NAS will instead send an LCP Configure-Request packet, described in 206 [6]. The Client MAY then renegotiate LCP, and from that point forward, 207 all PPP packets originated from the client will be encapsulated and sent 208 to the tunnel server. 210 Since address assignment will occur at the tunnel server, the client and 211 NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will occur 212 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 the 217 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 to 228 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 shared 233 by the client and proxy, rather than the RADIUS server. As a result, 234 this scheme is impractical. 235 .NH 3 Tunnel server authentication 237 In this scheme, authentication and authorization occurs once at the 238 tunnel server. This requires that the NAS determine that the user needs 239 to be tunneled (through RADIUS or NAS configuration). Where RADIUS is 240 used, the determination can be made using one of the following methods: 242 Telephone-number based authentication 243 UserID 245 7.1.2.1. Telephone-number based authentication 247 Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, 248 authorization and subsequent tunnel attributes can be based on the phone 249 number originating the call, or the number being called. This allows the 250 RADIUS server to authorize users based on the calling phone number or to 251 provide tunnel attributes based on the Calling-Station-Id or Called- 252 Station-Id. Similarly, in L2TP the tunnel server MAY choose to reject 253 or accept the call based on the Dialed Number and Dialing Number 254 included in the L2TP Incoming-Call-Request packet sent by the NAS. 255 Accounting can also take place based on the Calling-Station-Id and 256 Called-Station-Id. 258 RADIUS as defined in [1] requires that an Access-Request packet contain 259 a User-Name attribute as well as either a CHAP-Password or User-Password 260 attribute, which must be non-empty. To satisfy this requirement the 261 Called-Station-Id or Calling-Station-Id MAY be furnished in the User- 262 Name attribute and a dummy value MAY be used in the User-Password or 263 CHAP-Password attribute. 265 In the case of telephone-number based authentication, a typical 266 initiation sequence looks like this: 268 Client and NS: Call Connected 269 NAS to RADIUS Server: RADIUS Access-request 270 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 271 NAS to Tunnel Server: L2TP Incoming-Call-Request 272 Tunnel Server to NAS: L2TP Incoming-Call-Reply 273 NAS to Tunnel Server: L2TP Incoming-Call-Connected 274 Client and Tunnel Server: PPP LCP negotiation 275 Client and Tunnel Server: PPP authentication 276 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 277 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 278 Client and Tunnel Server: NCP negotiation 280 The process begins with an incoming call to the NAS. If configured for 281 telephone-number based authentication, the NAS sends a RADIUS Access- 282 Request containing the Calling-Station-Id and the Called-Station-Id 283 attributes. The RADIUS server will then respond with a RADIUS Access- 284 Accept or Access-Reject. 286 The NAS MUST NOT begin PPP authentication before bringing up the tunnel. 287 If timing permits, the NAS MAY bring up the tunnel prior to beginning 288 LCP negotiation with the peer. If this is done, then LCP will not need 289 to be renegotiated between the peer and tunnel server, nor will LCP 290 forwarding need to be employed. 292 If the initial telephone-number based authentication is unsuccessful, 293 the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS 294 MUST send an LCP-Terminate and disconnect the user. 296 In the case where tunnel attributes are included in the RADIUS Access- 297 Accept, and an L2TP tunnel is indicated, the NAS will now bring up a 298 control connection if none existed before. This is accomplished by 299 sending an L2TP Start-Control-Connection-Request message to the tunnel 300 server. The tunnel server will then reply with an L2TP Start-Control- 301 Connection-Reply. If this message indicates an error, or if the control 302 connection is terminated at any future time, then the NAS MUST send an 303 LCP-Terminate and disconnect the user. 305 The NAS will then send an L2TP Incoming-Call-Request message to the 306 tunnel server. Among other things, this message will contain the Call 307 Serial Number, which along with the NAS-IP-Address and Tunnel-Server- 308 Endpoint is used to uniquely identify the call. The tunnel server will 309 reply with an L2TP Incoming-Call-Reply message. If this message 310 indicates an error, then the NAS MUST send an LCP-Terminate and 311 disconnect the user. If no error is indicated, the NAS then replies with 312 an L2TP Incoming-Call-Connected message. 314 At this point, data can begin to flow through the tunnel. If LCP 315 negotiation had been begun between the NAS and the client, then LCP 316 forwarding may be employed, or the client and tunnel server will now 317 renegotiate LCP and begin PPP authentication. Otherwise, the client and 318 tunnel server will negotiate LCP for the first time, and then move on to 319 PPP authentication. 321 If a renegotiation is required, at the time that the renegotiation 322 begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP 323 negotiation, and the client and NAS MUST NOT have begun NCP negotiation. 324 Rather than sending an LCP CONFACK, the NAS will instead send an LCP 325 Configure-Request Packet, described in [6]. The Client MAY then 326 renegotiate LCP, and from that point forward, all PPP packets originated 327 from the client will be encapsulated and sent to the tunnel server. 328 When LCP re-negotiation has been concluded, the NCP phase will begin, 329 and the tunnel server will assign an address to the client. 331 If L2TP is being used as the tunnel protocol, and LCP renegotiation is 332 required, the NAS MAY in its initial setup notification include a copy 333 of the LCP CONFACKs sent in each direction which completed LCP 334 negotiation. The tunnel server MAY then use this information to avoid an 335 additional LCP negotiation. With L2TP, the initial setup notification 336 can also include the authentication information required to allow the 337 tunnel server to authenticate the user and decide to accept or decline 338 the connection. However, in telephone-number based authentication, PPP 339 authentication MUST NOT occur prior to the NAS bringing up the tunnel. 340 As a result, L2TP authentication forwarding MUST NOT be employed. 342 In performing the PPP authentication, the tunnel server can access its 343 own user database, or alternatively can send a RADIUS Access-Request. 344 The latter approach is useful in cases where authentication forwarding 345 is enabled, such as with roaming or shared use networks. In this case, 346 the RADIUS and tunnel servers are under the same administration and are 347 typically located close together, possibly on the same LAN. Therefore 348 having the tunnel server act as a RADIUS client provides for unified 349 user administration. Note that the tunnel server's RADIUS Access-Request 350 is typically sent directly to the local RADIUS server rather than being 351 forwarded via a proxy. 353 The interactions involved in initiation of a compulsory tunnel with 354 telephone-number based authentication are summarized below. In order to 355 simplify the diagram that follows, we have left out the client. However, 356 it is understood that the client participates via PPP negotiation, 357 authentication and subsequent data interchange with the Tunnel Server. 359 INITIATION SEQUENCE 361 NAS Tunnel Server RADIUS Server 362 --- ------------- ------------- 363 Call connected 364 Send RADIUS 365 Access-Request 366 with Called-Station-Id, 367 and/or Calling-Station-Id 368 LCP starts 369 IF authentication 370 succeeds 371 Send ACK 372 ELSE Send NAK 373 IF NAK DISCONNECT 374 ELSE 375 IF no control 376 connection exists 377 Send 378 Start-Control-Connection-Request 379 to Tunnel Server 380 Send 381 Start-Control-Connection-Reply 382 to NAS 383 ENDIF 385 Send 386 Incoming-Call-Request 387 message to Tunnel Server 388 Send Incoming-Call-Reply 389 to NAS 390 Send 391 Incoming-Call-Connected 392 message to Tunnel Server 394 Send data through the tunnel 395 Re-negotiate LCP, 396 authenticate user, 397 bring up IPCP, 398 start accounting 400 7.1.2.2. User-Name 402 Since authentication will occur only at the tunnel-server, tunnel 403 initiation must occur prior to user authentication at the NAS. As a 404 result, this scheme typically uses either the domain portion of the 405 userID or attribute-specific processing on the RADIUS server. Since the 406 user identity is never verified by the NAS, either the tunnel server 407 owner must be willing to be billed for all incoming calls, or other 408 information such as the Calling-Station-Id must be used to verify the 409 user's identity for accounting purposes. 411 In attribute-specific processing RADIUS may be employed and an attribute 412 is used to signal tunnel initiation. For example, tunnel attributes can 413 be sent back if the User-Password attribute contains a dummy value (such 414 as "tunnel" or "L2TP"). Alternatively, a userID beginning with a special 415 character ('*') could be used to indicate the need to initiate a tunnel. 416 When attribute-specific processing is used, the tunnel server may need 417 to renegotiate LCP. 419 Another solution involves using the domain portion of the userID; all 420 users in domain X would be tunneled to address Y. This proposal supports 421 compulsory tunneling, but does not provide for user-based tunneling. 423 In order for the NAS to start accounting on the connection, it would 424 need to use the identity claimed by the user in authenticating to the 425 tunnel server, since it did not verify the identity via RADIUS. However, 426 in order for that to be of any use in accounting, the tunnel endpoint 427 needs to have an account relationship with the NAS owner. Thus even if a 428 user has an account with the NAS owner, they cannot use this account for 429 tunneling unless the tunnel endpoint also has a business relationship 430 with the NAS owner. Thus this approach is incompatible with roaming. 432 A typical initiation sequence involving use of the domain portion of the 433 userID looks like this: 435 Client and NAS: Call Connected 436 Client and NAS: PPP LCP negotiation 437 Client and NAS: Authentication 438 NAS to Tunnel Server: L2TP Incoming-Call-Request 439 Tunnel Server to NAS: L2TP Incoming-Call-Reply 440 NAS to Tunnel Server: L2TP Incoming-Call-Connected 441 Client and Tunnel Server: PPP LCP re-negotiation 442 Client and Tunnel Server: PPP authentication 443 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 444 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 445 Client and Tunnel Server: NCP negotiation 447 The process begins with an incoming call to the NAS, and the PPP LCP 448 negotiation between the Client and NAS. The authentication process will 449 then begin and based on the domain portion of the userID, the NAS will 450 now bring up a control connection if none existed before, and the NAS 451 and tunnel server will bring up the call. At this point, data MAY begin 452 to flow through the tunnel. The client and tunnel server MAY now 453 renegotiate LCP and will complete PPP authentication. 455 At the time that the renegotiation begins, the NAS SHOULD NOT have sent 456 an LCP CONFACK completing LCP negotiation, and the client and NAS MUST 457 NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the 458 NAS will instead send an LCP Configure-Request packet, described in [6]. 459 The Client MAY then renegotiate LCP, and from that point forward, all 460 PPP packets originated from the client will be encapsulated and sent to 461 the tunnel server. In single authentication compulsory tunneling, L2TP 462 authentication forwarding MUST NOT be employed. When LCP re-negotiation 463 has been concluded, the NCP phase will begin, and the tunnel server will 464 assign an address to the client. 466 In performing the PPP authentication, the tunnel server can access its 467 own user database, or it MAY send a RADIUS Access-Request. After the 468 tunnel has been brought up, the NAS and tunnel server can start 469 accounting. 471 The interactions are summarized below. 473 INITIATION SEQUENCE 475 NAS Tunnel Server RADIUS Server 476 --- ------------- ------------- 477 Call accepted 478 LCP starts 479 Authentication 480 phase starts 481 IF no control 482 connection exists 483 Send 484 Start-Control-Connection-Request 485 to Tunnel Server 486 ENDIF 487 IF no control 488 connection exists 489 Send 490 Start-Control-Connection-Reply 491 to NAS 492 ENDIF 494 Send 495 Incoming-Call-Request 496 message to Tunnel Server 497 Send Incoming-Call-Reply 498 to NAS 499 Send 500 Incoming-Call-Connected 501 message to Tunnel Server 503 Send data through the tunnel 504 Re-negotiate LCP, 505 authenticate user, 506 bring up IPCP, 507 start accounting 509 7.2. Dual authentication 511 In this scheme, authentication occurs both at the NAS and the tunnel 512 server. This requires the dial-up client to handle dual authentication, 513 with attendant LCP re-negotiations. In order to allow the NAS and tunnel 514 network server to authenticate against the same database, this requires 515 RADIUS client capability on the tunnel network server, and possibly a 516 RADIUS proxy on the NAS end. 518 Advantages of dual authentication include support for authentication and 519 accounting at both ends of the tunnel; use of a single userID/password 520 pair via implementation of RADIUS on the tunnel network server; no 521 requirement for telephone-number based authentication, or attribute- 522 specific processing on the RADIUS server. 524 Dual authentication allows for accounting records to be generated on 525 both the NAS and tunnel server ends, making auditing possible. Also the 526 tunnel endpoint does not need to have an account relationship with the 527 NAS owner, making this approach compatible with roaming. 529 A disadvantage of dual authentication is that unless LCP forwarding is 530 used, LCP will need to be renegotiated; some clients do not support it 531 at all, and others only support only a subset of the dual authentication 532 combinations. Feasible combinations include PAP/PAP(token), PAP/CHAP, 533 PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and EAP/EAP. 534 EAP is described in [5]. 536 In the case of a dual authentication, a typical initiation sequence 537 looks like this: 539 Client and NAS: PPP LCP negotiation 540 Client and NAS: PPP authentication 541 NAS to RADIUS Server: RADIUS Access-request 542 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 543 NAS to Tunnel Server: L2TP Incoming-Call-Request 544 Tunnel Server to NAS: L2TP Incoming-Call-Reply 545 NAS to Tunnel Server: L2TP Incoming-Call-Connected 546 Client and Tunnel Server: PPP LCP re-negotiation (optional) 547 Client and Tunnel Server: PPP authentication 548 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 549 RADIUS server to Tunel Server: RADIUS Access-Accept/Access-Reject 550 Client and Tunnel Server: NCP negotiation 552 The process begins with an incoming call to the NAS. The client and NAS 553 then begin LCP negotiation. Subsequently the PPP authentication phase 554 starts, and the NAS sends a RADIUS Access-Request message to the RADIUS 555 server. If the authentication is successful, the RADIUS server responds 556 with a RADIUS Access-Accept containing tunnel attributes. 558 In the case where an L2TP tunnel is indicated, the NAS will now bring up 559 a control connection if none existed before, and the NAS and tunnel 560 server will bring up the call. At this point, data MAY begin to flow 561 through the tunnel. The client and tunnel server MAY now renegotiate LCP 562 and go through another round of PPP authentication. At the time that 563 this renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK 564 completing LCP negotiation, and the client and NAS MUST NOT have begun 565 NCP negotiation. Rather than sending an LCP CONFACK, the NAS will 566 instead send an LCP Configure-Request packet, described in [6]. The 567 Client MAY then renegotiate LCP, and from that point forward, all PPP 568 packets originated from the client will be encapsulated and sent to the 569 tunnel server. When LCP re-negotiation has been concluded, the NCP 570 phase will begin, and the tunnel server will assign an address to the 571 client. 573 If L2TP is being used as the tunnel protocol, the NAS MAY in its initial 574 setup notification include a copy of the LCP CONFACKs sent in each 575 direction which completed LCP negotiation. The tunnel server MAY then 576 use this information to avoid an additional LCP negotiation. With L2TP, 577 the initial setup notification can also include the authentication 578 information required to allow the tunnel server to authenticate the user 579 and decide to accept or decline the connection. However, this facility 580 creates a vulnerability to replay attacks, and can create problems in 581 the case where the NAS and tunnel server authenticate against different 582 RADIUS servers. As a result, where user-based tunneling via RADIUS is 583 implemented, L2TP authentication forwarding SHOULD NOT be employed. 585 In performing the PPP authentication, the tunnel server can access its 586 own user database, or it MAY send a RADIUS Access-Request. After the 587 tunnel has been brought up, the NAS and tunnel server can start 588 accounting. 590 The interactions involved in initiation of a compulsory tunnel with dual 591 authentication are summarized below. 593 INITIATION SEQUENCE 595 NAS Tunnel Server RADIUS Server 596 --- ------------- ------------- 597 Call accepted 598 LCP starts 599 PPP authentication 600 phase starts 601 Send RADIUS 602 Access-Request 603 with username and 604 authentication data 605 IF authentication 606 succeeds 607 Send ACK 608 ELSE Send NAK 609 IF NAK DISCONNECT 610 ELSE 611 IF no control 612 connection exists 613 Send 614 Start-Control-Connection-Request 615 to Tunnel Server 616 Send 617 Start-Control-Conection-Reply 618 to NAS 619 ENDIF 621 Send 622 Incoming-Call-Request 623 message to Tunnel Server 624 Send Incoming-Call-Reply 625 to NAS 626 Send 627 Incoming-Call-Connected 628 message to Tunnel Server 630 Send data through the tunnel 631 Re-negotiate LCP, 632 authenticate user, 633 bring up IPCP, 634 start accounting 635 ENDIF 637 8. Termination sequence 639 The tear down of a compulsory tunnel involves an interaction between the 640 client, NAS and Tunnel Server. This interaction is virtually identical 641 regardless of whether telephone-number based authentication, single 642 authentication, or dual authentication is being used. In any of the 643 cases, the following events occur: 645 Tunnel Server to NAS: L2TP Call-Clear-Request (optional) 646 NAS to Tunnel Server: L2TP Call-Disconnect-Notify 648 Tunnel termination can occur due to a client request (PPP termination), 649 a tunnel server request (Call-Clear-Request), or a line problem (call 650 disconnect). 652 In the case of a client-requested termination, the tunnel server MUST 653 terminate the PPP session. The tunnel server MUST subsequently send a 654 Call-Clear-Request to the NAS. The NAS MUST then send a Call-Disconnect- 655 Notify message to the tunnel server, and will disconnect the call. 657 The NAS MUST also respond with a Call-Disconnect-Notify message and 658 disconnection if it receives a Call-Clear-Request from the tunnel server 659 without a client-requested termination. 661 In the case of a line problem or user hangup, the NAS MUST send a Call- 662 Disconnect-Notify to the tunnel server. Both sides will then tear down 663 the call. 665 The interactions involved in termination of a compulsory tunnel are 666 summarized below. In order to simplify the diagram that follows, we have 667 left out the client. However, it is understood that the client MAY 668 participate via PPP termination and disconnection. 670 TERMINATION SEQUENCE 672 NAS Tunnel Server RADIUS Server 673 --- ------------- ------------- 674 IF user disconnected 675 send 676 Call-Disconnect-Notify 677 message to tunnel server 678 Tear down the call 679 stop accounting 680 ELSE IF client equests 681 termination 682 send 683 Call-Clear-Request 684 to the NAS 685 Send 686 Call-Disconnect-Notify 687 message to tunnel server 688 Disconnect the user 689 Tear down the call 690 stop accounting 691 ENDIF 693 9. Use of distinct RADIUS servers 695 In the case that the NAS and the tunnel server are using distinct RADIUS 696 servers, some interesting cases can arise in the provisioning of 697 compulsory tunnels. 699 9.1. Distinct userIDs 701 If distinct RADIUS servers are being used, it is likely that distinct 702 userID/password pairs will be required to complete the RADIUS and tunnel 703 authentications. One pair will be used in the initial PPP authentication 704 with the NAS, and the second pair will be used for authentication at the 705 tunnel server. 707 This has implications if the NAS attempts to forward authentication 708 information to the tunnel server in the initial setup notification. 709 Since the userID/password pair used for tunnel authentication is 710 different from that used to authenticate against the NAS, forwarding 711 authentication information in this manner will cause the tunnel 712 authentication to fail. As a result, where user-based tunneling via 713 RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be 714 employed. 716 In order to provide maximum ease of use in the case where the 717 userID/password pairs are identical, tunnel clients typically attempt 718 authentication with the same userID/password pair as was used in the 719 initial PPP negotiation. Only after this fails do they prompt the user 720 for the second pair. Rather than putting up an error message indicating 721 an authentication failure, it is preferable to present a dialog 722 requesting the tunnel userID/password combination. 724 A similar issue arises when extended authentication methods are being 725 used, as is enabled by EAP, described in [5]. In particular, when one- 726 time passwords or cryptographic calculators are being used, different 727 passwords will be used for the first and second authentications. Thus 728 the user will need to be prompted to enter the second password. 730 9.2. Multilink PPP issues 732 It is possible for the two RADIUS servers to return different Port-Limit 733 attributes. For example, it is conceivable that the NAS RADIUS server 734 will only grant use of a single channel, while the tunnel RADIUS server 735 will grant more than one channel. In this case, the correct behavior is 736 for the tunnel client to open a connection to another NAS in order to 737 bring up a multilink bundle on the tunnel server. The client MUST NOT 738 indicate to the NAS that this additional link is being brought up as 739 part of a multilink bundle; this will only be indicated in the 740 subsequent negotiation with the tunnel server. 742 It is also conceivable that the NAS RADIUS server will allow the client 743 to bring up multiple channels, but that the tunnel RADIUS server will 744 allow fewer channels than the NAS RADIUS server. In this case, the 745 client should terminate use of the excess channels. 747 10. UserID Issues 749 In the provisioning of roaming and shared use networks, one of the 750 requirements is to be able to route the authentication request to the 751 user's home RADIUS server. This authentication routing is accomplished 752 based on the userID submitted by the user to the NAS in the initial PPP 753 authentication. The userID is subsequently relayed by the NAS to the 754 RADIUS server in the User-Name attribute, as part of the RADIUS Access- 755 Request. 757 Similarly, [2] refers to use of the userID in determining the tunnel 758 endpoint, although it does not provide guidelines for how RADIUS or 759 tunnel routing is to be accomplished. Thus the possibility of 760 conflicting interpretations exists. 762 The use of RADIUS in provisioning of compulsory tunneling relieves the 763 userID from having to do double duty. Rather than being used both for 764 routing of the RADIUS authentication/authorization request as well for 765 determination of the tunnel endpoint, the userID is now used solely for 766 routing of RADIUS authentication/authorization requests. Tunnel 767 attributes returned in the RADIUS Access-Response are then used to 768 determine the tunnel endpoint. 770 Since the framework described in this document allows both ISPs and 771 tunnel users to authenticate users as well as to account for resources 772 consumed by them, and provides for maintenance of two distinct 773 userID/password pairs, this scheme provides a high degree of 774 flexibility. Where RADIUS proxies and tunneling are employed, it is 775 possible to allow the user to authenticate with a single userID/password 776 pair at both the NAS and the tunnel endpoint. This is accomplished by 777 routing the NAS RADIUS Access-Request to the same RADIUS server used by 778 the tunnel server. 780 11. References 782 [1] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote 783 Authentication Dial In User Service (RADIUS)", RFC 2138, April 784 1997. 786 [2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 787 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 788 1999. 790 [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 791 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", 792 Internet draft (work in progress), draft-ietf-radius-tunnel- 793 auth-09.txt, August 1999. 795 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 796 Levels", BCP 14, RFC 2119, March 1997. 798 [5] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 799 (EAP)", RFC 2284, March 1998. 801 [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, 802 RFC 1661, July 1994. 804 12. Security considerations 806 In PPP-based tunneling, PPP security is negotiated between the client 807 and the tunnel server, and covers the entire length of the path. This is 808 because the client does not have a way to know that they are being 809 tunneled. Thus, any security the NAS may negotiate with the tunnel 810 server will occur in addition to that negotiated between the client and 811 NAS. 813 In L2TP compulsory tunneling, this means that PPP encryption and 814 compression will be negotiated between the client and the tunnel server. 815 In addition, the NAS may bring up an IPSEC security association between 816 itself and the tunnel server. This adds protection against a number of 817 possible attacks. 819 Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS 820 server may be processed by one or more proxies prior to being received 821 by the NAS. In order to ensure that tunnel attributes arrive without 822 modification, intermediate RADIUS proxies forwarding the Access-Reply 823 MUST NOT modify tunnel attributes. If the RADIUS proxy does not support 824 tunnel attributes, then it MUST send an Access-Reject to the NAS. This 825 is necessary to ensure that the user is only granted access if the 826 services requested by the RADIUS server can be provided. 828 Since RADIUS tunnel attributes are used for compulsory tunneling, 829 address assignment is handled by the tunnel server rather than the NAS. 830 As a result, if tunnel attributes are present, the NAS MUST ignore any 831 address assignment attributes sent by the RADIUS server. In addition, 832 the NAS and client MUST NOT begin NCP negotiation, since this could 833 create a time window in which the client will be capable of sending 834 packets to the transport network, which is not permitted in compulsory 835 tunneling. 837 13. Acknowledgements 839 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions of 840 this problem space, and to Allan Rubens of Ascend and Bertrand Buclin of 841 AT&T Labs Europe for his comments on this document. 843 14. Chair's Address 845 The RADIUS Working Group can be contacted via the current chair: 847 Carl Rigney 848 Livingston Enterprises 849 4464 Willow Road 850 Pleasanton, California 94588 852 Phone: +1 510-426-0770 853 E-Mail: cdr@livingston.com 855 15. Authors' Addresses 857 Bernard Aboba 858 Microsoft Corporation 859 One Microsoft Way 860 Redmond, WA 98052 862 Phone: +1 425-936-6605 863 EMail: bernarda@microsoft.com 865 Glen Zorn 866 Microsoft Corporation 867 One Microsoft Way 868 Redmond, WA 98052 870 Phone: +1 425-703-1559 871 EMail: glennz@microsoft.com 873 16. Intellectual Property Statement 875 The IETF takes no position regarding the validity or scope of any 876 intellectual property or other rights that might be claimed to pertain 877 to the implementation or use of the technology described in this 878 document or the extent to which any license under such rights might or 879 might not be available; neither does it represent that it has made any 880 effort to identify any such rights. Information on the IETF's 881 procedures with respect to rights in standards-track and standards- 882 related documentation can be found in BCP-11. Copies of claims of 883 rights made available for publication and any assurances of licenses to 884 be made available, or the result of an attempt made to obtain a general 885 license or permission for the use of such proprietary rights by 886 implementors or users of this specification can be obtained from the 887 IETF Secretariat. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary rights 891 which may cover technology that may be required to practice this 892 standard. Please address the information to the IETF Executive 893 Director. 895 17. Full Copyright Statement 897 Copyright (C) The Internet Society (1999). All Rights Reserved. 898 This document and translations of it may be copied and furnished to 899 others, and derivative works that comment on or otherwise explain it or 900 assist in its implmentation may be prepared, copied, published and 901 distributed, in whole or in part, without restriction of any kind, 902 provided that the above copyright notice and this paragraph are included 903 on all such copies and derivative works. However, this document itself 904 may not be modified in any way, such as by removing the copyright notice 905 or references to the Internet Society or other Internet organizations, 906 except as needed for the purpose of developing Internet standards in 907 which case the procedures for copyrights defined in the Internet 908 Standards process must be followed, or as required to translate it into 909 languages other than English. The limited permissions granted above are 910 perpetual and will not be revoked by the Internet Society or its 911 successors or assigns. This document and the information contained 912 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 913 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 914 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 915 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 918 18. Expiration Date 920 This memo is filed as , and 921 expires March 1, 2000.