idnits 2.17.1 draft-ietf-radius-tunnel-imp-03.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-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 27 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 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 a Security Considerations 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 400 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 668 instances of too long lines in the document, the longest one being 14 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 101: '...he Network Access Identifier (NAI) MAY...' RFC 2119 keyword, line 104: '...his same structure MAY also be used to...' RFC 2119 keyword, line 113: '... MUST This word, or the ad...' RFC 2119 keyword, line 117: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 120: '... SHOULD This word, or the adjec...' (92 more instances...) 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...' == (395 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 (26 July 1997) is 9770 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? '3' on line 1315 looks like a reference -- Missing reference section? '4' on line 1319 looks like a reference -- Missing reference section? '9' on line 1341 looks like a reference -- Missing reference section? '7' on line 1333 looks like a reference -- Missing reference section? '6' on line 1328 looks like a reference -- Missing reference section? '10' on line 1344 looks like a reference -- Missing reference section? '11' on line 1347 looks like a reference -- Missing reference section? '12' on line 1352 looks like a reference -- Missing reference section? '13' on line 1357 looks like a reference -- Missing reference section? '5' on line 1322 looks like a reference -- Missing reference section? '8' on line 1337 looks like a reference -- Missing reference section? '1' on line 1307 looks like a reference -- Missing reference section? '2' on line 1311 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 15 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 26 July 1997 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 February 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 This specification uses the same words as [9] for defining the signif- 111 icance of each particular requirement. These words are: 113 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 114 that the definition is an absolute requirement of the speci- 115 fication. 117 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 118 nition is an absolute prohibition of the specification. 120 SHOULD This word, or the adjective "RECOMMENDED", means that there 121 MAY exist valid reasons in particular circumstances to 122 ignore a particular item, but the full implications must be 123 understood and carefully weighed before choosing a different 124 course. 126 SHOULD NOT 127 This phrase means that there MAY exist valid reasons in par- 128 ticular circumstances when the particular behavior is 129 acceptable or even useful, but the full implications should 130 be understood and the case carefully weighed before imple- 131 menting any behavior described with this label. 133 MAY This word, or the adjective "OPTIONAL", means that an item 134 is truly optional. One vendor may choose to include the 135 item because a particular marketplace requires it or because 136 the vendor feels that it enhances the product while another 137 vendor may omit the same item. An implementation which does 138 not include a particular option MUST be prepared to interop- 139 erate with another implementation which does include the 140 option, though perhaps with reduced functionality. In the 141 same vein an implementation which does include a particular 142 option MUST be prepared to interoperate with another imple- 143 mentation which does not include the option.(except, of 144 course, for the feature the option provides) 146 Silently Discard 147 The implementation discards the datagram without further 148 processing, and without indicating an error to the sender. 149 The implementation SHOULD provide the capability of logging 150 the error, including the contents of the discarded datagram, 151 and SHOULD record the event in a statistics counter. 153 An implementation is not compliant if it fails to satisfy one or more 154 of the MUST or MUST NOT requirements for the protocols it implements. 155 An implementation that satisfies all the MUST, MUST NOT, SHOULD and 156 SHOULD NOT requirements for its protocols is said to be 157 "unconditionally compliant"; one that satisfies all the MUST and MUST 158 NOT requirements but not all the SHOULD or SHOULD NOT requirements for 159 its protocols is said to be "conditionally compliant." 161 5. Introduction 163 Many applications of tunneling protocols involve dial-up network 164 access. Some, such as the provisioning of secure access to corporate 165 intranets via the Internet, are characterized by voluntary tunneling: 166 the tunnel is created at the request of the user for a specific pur- 167 pose. Other applications involve compulsory tunneling: the tunnel is 168 created without any action from the user and without allowing the user 169 any choice. 171 Examples of applications that might be implemented using compulsory 172 tunnels are Internet software upgrade servers, software registration 173 servers and banking services. These are all services which, without 174 compulsory tunneling, would probably be provided using dedicated net- 175 works or at least dedicated network access servers (NAS), since they 176 are characterized by the need to limit user access to specific hosts. 178 Given the existence of widespread support for compulsory tunneling, 179 however, these types of services could be accessed via any Internet 180 service provider (ISP). The most popular means of authorizing dial-up 181 network users today is through the RADIUS protocol. The use of 182 RADIUS allows the dial-up users' authorization and authentication data 183 to be maintained in a central location, rather than on each NAS. It 184 makes sense to use RADIUS to centrally administer compulsory tun- 185 neling, since RADIUS is widely deployed and was designed to 186 carry this type of information. New RADIUS attributes are needed to 187 carry the tunneling information from the RADIUS server to the NAS 188 and to transfer accounting data from the NAS to the RADIUS accounting 189 server; those attributes are defined in [7]. 191 5.1. Tunneling attributes 193 As described in [7], provisioning of compulsory tunneling with RADIUS 194 requires no new RADIUS messages, and implementation of five new RADIUS 195 attributes: Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client-End- 196 point, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection-Id. 198 The Tunnel-Type attribute indicates the tunneling protocol(s) to be 199 used (PPTP, L2F, L2TP, ATMP, VTP, IPSEC AH, IP-IP). It MAY be included 200 in Access-Request, Access-Accept, and Access-Challenge packets. 202 The Tunnel-Medium-Type Attribute indicates which transport medium to 203 use (IP, X.25, ATM, Frame Relay) when creating a tunnel for those pro- 204 tocols (such as L2TP) that can operate over multiple transports. 205 It MAY be included in in Access-Request, Access-Accept, and Access- 206 Challenge packets. 208 Acct-Tunnel-Client-Endpoint contains the address of the NAS end of the 209 tunnel. It SHOULD be included in Accounting-Request packets which 210 contain Acct-Status-Type attributes with values of either Start or 211 Stop. This Attribute, along with the Tunnel-Server-Endpoint and 212 Acct-Tunnel-Connection-ID attributes, may be used to provide a glob- 213 ally unique means to identify a tunnel for accounting purposes. 215 Tunnel-Server-Endpoint indicates the address of the server end of the 216 tunnel. It SHOULD be included in Accounting-Request packets which 217 contain Acct-Status-Type attributes with values of either Start or 218 Stop. 220 Acct-Tunnel-Connection-ID indicates the identifier assigned to the 221 call. It SHOULD be included in Accounting-Request packets which 222 contain Acct-Status-Type attributes with values of either Start or 223 Stop. 225 Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS 226 server may be processed by one or more proxies prior to being received 227 by the NAS. In order to ensure that tunnel attributes arrive without 228 modification, intermediate RADIUS proxies forwarding the Access-Reply 229 MUST NOT modify tunnel attributes. If the RADIUS proxy does not sup- 230 port tunnel attributes, then it MUST send an Access-Reject to the NAS. 231 This is necessary to ensure that the user is only granted access if 232 the services requested by the RADIUS server can be provided. 234 Since RADIUS tunnel attributes are used for compulsory tunneling, 235 address assignment is handled by the tunnel server rather than the 236 NAS. As a result, if tunnel attributes are present, the NAS MUST 237 ignore any address assignment attributes sent by the RADIUS server. In 238 addition, the NAS and client MUST NOT begin NCP negotiation, since 239 this could create a time window in which the client will be capable of 240 sending packets to the transport network, which is not permitted under 241 compulsory tunneling. 243 5.2. Advantanges of RADIUS-based compulsory tunneling 245 The use of RADIUS in provisioning of compulsory tunnels has several 246 advantages. These include: 248 User-based tunneling 249 Auditing capabilities 250 Telephone-number based authentication and accounting 251 Single or dual authentication 253 5.2.1. User-based Tunneling 255 Current proposals for routing of tunnel requests include static tun- 256 neling, where all users are automatically tunneled to a given end- 257 point, and realm-based tunneling, where the tunnel endpoint is deter- 258 mined from the realm portion of the userID. User-based tunneling as 259 provided by integration of RADIUS and tunnel protocols offers 260 significant advantages over both of these approaches. 262 Static tunneling requires dedication of a NAS device to the purpose. 263 In the case of an ISP, this is undesirable because it requires them to 264 dedicate a NAS to tunneling service for a given corporate customer, 265 rather than allowing them to use existing NASes deployed in the field. 266 As a result static tunneling is likely to be costly for deployment of 267 a global service. 269 Realm-based tunneling assumes that all users within a given realm wish 270 to be treated the same way. This limits a corporation's flexibility in 271 managing the account rights of their users. For example, BIGCO may 272 desire to provide Janet with an account that allows access to both the 273 Internet and the intranet, with Janet's intranet access provided by a 274 tunnel server located in the engineering department. However BIGCO may 275 desire to provide Fred with an account that provides only access to 276 the intranet, with Fred's intranet access provided by a tunnel network 277 server located in the sales department. Such a situation cannot be 278 accommodated with realm-based tunneling. 280 On the other hand, user-based tunneling as enabled by the attributes 281 defined in [7] provides BIGCO with the flexibility to administer tun- 282 neling behavior on a per-user basis. When deployed in concert with 283 roaming, user-based tunneling offers corporations the ability to pro- 284 vide their users with access to the corporate Intranet on a global 285 basis. 287 5.3. Auditing Capabilities 289 The integration of RADIUS and tunnel protocols allows the ISP and the 290 corporation to synchronize their accounting activities so that each 291 side receives a record of the user's resource consumption. This pro- 292 vides the corporation with the means to audit ISP bills. 294 The Acct-Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID 295 attributes were introduced in [7] in order to support auditing. These 296 attributes are included within the RADIUS Accounting-Request packet 297 along with other attributes such as the User-Name and Tunnel-Server- 298 Endpoint. During accounting, the User-Name, Acct-Tunnel-Connection- 299 ID, Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes 300 uniquely identify the call. This allows the Accounting-Request sent by 301 the NAS to be reconciled with the corresponding Accounting-Request 302 sent by the tunnel server. 304 When implementing L2TP compulsory tunneling based on RADIUS, the NAS 305 MUST transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID 306 attribute in the Accounting-Request packet. In order to protect 307 against wrapping due to reboots or call volume, a 64-bit NTP timestamp 308 SHOULD be used as the Call-Serial Number. This feasible in L2TP since 309 the Call-Serial-Number string is of variable length. 311 When implementing PPTP compulsory tunneling based on RADIUS, the NAS 312 MUST transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID 313 attribute in the Accounting-Request packet. While [6] states that the 314 Call-Serial-Number SHOULD be unique, this is not required. In addi- 315 tion, no method for determining the Call-Serial-Number is specified, 316 which leaves open the possibility of wrapping after a reboot. 318 Since the Call-Serial-Number is a 16-bit value, the Call-Serial-Number 319 is not sufficient to distinguish a given call from all other calls 320 over an extended time period. For example, let us assume that the Call 321 Serial Number is assigned monotonically, and that the NAS in question 322 has 96 ports. If the NAS ports are kept continually busy and the aver- 323 age call is of 20 minutes duration, then the Call Serial Number will 324 wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.5 days. 326 In order to rectify this, it is recommended that another message be 327 added to PPTP so that the NAS could provide the tunnel server with an 328 Acct-Tunnel-Connection-ID unique over an extended time period. It is 329 recommended that a 64-bit NTP timestamp be used for this purpose. 331 5.4. Telephone-number based authentication and accounting 333 Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, 334 authorization and subsequent tunnel attributes can be based on the 335 phone number originating the call, or the number being called. This 336 allows the RADIUS server to authorize users based on the calling phone 337 number (with or without a userID/password combination), or to select 338 the Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Server-Endpoint 339 attributes based on the Calling-Station-Id or Called-Station-Id. Sim- 340 ilarly, in PPTP/L2TP the tunnel server MAY choose to reject or accept 341 the call based on the Dialed Number and Dialing Number included in the 342 PPTP/L2TP Incoming-Call-Request packet sent by the NAS. 344 The use of RADIUS accounting by the NAS and/or the tunnel server 345 allows for accounting to take place based on the Calling-Station-Id 346 and Called-Station-Id. 348 5.5. Single or dual authentication 350 As described below, RADIUS-based compulsory tunneling can support a 351 variety of authentication configurations. These include single authen- 352 tication, where the user is authenticated at the tunnel server, or 353 dual authentication, where the user is authenticated at both the NAS 354 and the tunnel server. When single authentication is supported, a 355 variety of modes are possible, including telephone-number based 356 authentication described above, or EAP-based authentication. When 357 dual-authentication is used, a number of modes are available, includ- 358 ing dual CHAP authentications; CHAP/EAP authentication; 359 CHAP/PAP(token) authentication; and EAP/EAP authentication, using the 360 same EAP type for both authentications. 362 PAP/PAP, CHAP/PAP and EAP/PAP dual authentications SHOULD NOT be used, 363 since these combinations involve transmission of cleartext passwords 364 over the Internet. 366 6. Authentication alternatives in compulsory tunneling 368 There are several authentication alternatives for integration of 369 RADIUS and tunneling: 371 Authenticate at the NAS 372 Authenticate at the NAS, and forward the RADIUS reply 373 Authenticate at the tunnel network server 374 Authenticate at both the NAS and the tunnel network server 376 We discuss each of these alternatives in turn. 378 6.1. Authenticate at the NAS 380 With this approach, authentication and authorization (including tun- 381 neling information) occurs once, at the NAS. The advantages of this 382 approach are that it disallows network access for unauthorized NAS 383 users; and allows RADIUS accounting to be used at the NAS. Disadvan- 384 tages are that it requires that the tunnel network server trust the 385 NAS, since no user authentication occurs on the tunnel network server 386 end of the tunnel. Another disadvantage is that this does not allow 387 LCP parameters to be re-negotiated by the tunnel network server. Also, 388 due to the lack of user authentication, accounting cannot take place 389 at the tunnel network server with strong assurance that the correct 390 party is being billed. As a result, it does not appear that this 391 scheme can be practically employed. 393 6.2. Authenticate at the NAS, and forward the RADIUS reply 395 With this approach, authentication and authorization occurs once, at 396 the NAS end of the tunnel and the RADIUS reply is forwarded to the 397 tunnel network server. This approach disallows network access for 398 unauthorized NAS users; does not require trust between the NAS and 399 tunnel network server ends of the tunnel; and allows for RADIUS 400 accounting to be used at both ends of the tunnel. However, it also 401 requires that both ends share the same secret with the RADIUS server, 402 since that is the only way that the tunnel network server could check 403 the RADIUS reply. 405 In this approach, the tunnel network server MUST share secrets with 406 all the NASes and associated RADIUS servers, and there is no provision 407 for LCP renegotiation by the tunnel network server. Also, the tunnel 408 network server MUST know how to handle and verify RADIUS Access-Accept 409 messages. 411 While this scheme can be workable if the reply comes directly from a 412 RADIUS server, it would become unmanageable if a RADIUS proxy is 413 involved, since the reply would be authenticated using the secret 414 shared by the client and proxy, rather than the RADIUS server. As a 415 result, it does not appear that this scheme can be practically 416 employed. 418 6.3. Authenticate at the tunnel network server 420 In this scheme, authentication and authorization occurs once at the 421 tunnel network server. This requires that the NAS determine that the 422 user needs to be tunneled (through RADIUS or NAS configuration). Where 423 RADIUS is used, the determination can be made using one of the follow- 424 ing methods: 426 Telephone-number based authentication 427 User-Name 428 EAP Identity 430 6.3.1. Telephone-number based authentication 432 Where telephone-number based authentication is used, the Calling-Sta- 433 tion-Id or Called-Station-Id attributes included in the RADIUS Access- 434 Request are used to determine whether the call will be accepted or 435 rejected, and if accepted, where the user is to be tunneled. Where 436 telephone-number based authentication is used, the User-Name and User- 437 Password or CHAP-Password attributes need not be present. 439 In cases where telephone-number authentication may be employed, 440 accounting may be accomplished on the NAS side via the Calling-Sta- 441 tion-Id or Called-Station-Id, and on the tunnel server side, via the 442 userID. Thus this scheme is capable of providing both authentication 443 and accounting, and appears practical to implement. 445 6.3.2. User-Name 447 Where the User-Name attribute is present, RADIUS as defined in [3] 448 requires that either a CHAP-Password or User-Password attribute be 449 present in an Access-Request message, as well as requiring that the 450 password be non-empty. Thus, this scheme either requires attribute- 451 specific processing on the RADIUS server, or addition of an "Autho- 452 rize-Only" message. 454 In attribute-specific processing an attribute is used to signal tunnel 455 initiation. For example, tunnel attributes can be sent back if the 456 PAP password is empty (or "tunnel" or "L2TP"). Alternatively, a user 457 could prefix the userID with some special character ('*') if he wanted 458 to be tunneled. This particular solution does not support compulsory 459 tunneling. Another solution involves keying on the domain portion of 460 the userID; all users in domain X would be tunneled to address Y. 461 This proposal supports compulsory tunneling, but does not provide for 462 user-based tunneling. 464 An Authorize-Only message would not include a CHAP or PAP password; 465 nevertheless, in response the RADIUS server would return the attribute 466 list. In order to prevent password guessing attacks, an Authorize-Only 467 message would need to be authenticated via the RADIUS shared secret. 468 This could be accomplished via the Signature attribute described in 469 [10]. 471 Note that when either attribute-specific processing or an authorize- 472 only message is used, the tunnel network server would need to renego- 473 tiate LCP. Note also that in order for the NAS to start accounting on 474 the connection, it would need to use the identity claimed by the user 475 in authenticating to the tunnel network server, since it did not ver- 476 ify the identity via RADIUS. However, in order for that to be of any 477 use in accounting, the tunnel endpoint needs to have an account rela- 478 tionship with the NAS owner. Thus even if a user has an account with 479 the NAS owner, they cannot use this account for tunneling unless the 480 tunnel endpoint also has a business relationship with the NAS owner. 481 Without putting in place a public key infrastructure, it is not clear 482 how the NAS would be able to verify the existence of such a business 483 relationship in a scalable manner. Thus this approach nullifies many 484 of the benefits of roaming. Due to these difficulties, it does not 485 appear that this scheme can be practically employed. 487 6.3.3. EAP Identity 489 Where EAP is used as described in [11], the NAS may include an EAP- 490 Message/Identity attribute in the RADIUS Access-Request. Based on the 491 Identity included in the Access-Request, the RADIUS server may send 492 tunneling attributes within the RADIUS Access-Challenge packet. The 493 NAS can then set up the tunnel and EAP authentication may continue 494 between the client and the tunnel server. This method avoids having to 495 use attribute-specific processing or an authorize-only message. 497 However, in this case, the EAP identity is never verified by the NAS, 498 and so either the tunnel server owner must be willing to be billed for 499 all incoming calls, or other information such as the Calling-Station- 500 Id must be used to verify the user's identity for accounting purposes. 501 Where either of these conditions holds true, this scheme may be prac- 502 tically employed. 504 6.4. Authenticate at both the NAS and the tunnel network server 506 In this scheme, authentication occurs both at the NAS and the tunnel 507 network server. This requires the dial-up PPP peer to handle dual 508 authentications, with attendant LCP re-negotiations. In order to allow 509 the NAS and tunnel network server to authenticate against the same 510 database, this requires RADIUS client capability on the tunnel network 511 server, and possibly a RADIUS proxy on the NAS end. 513 Advantages of this scheme are that it allows secure authentication and 514 accounting at both ends of the tunnel; allows the use of a single 515 userID/password pair via implementation of RADIUS on the tunnel net- 516 work server; and does not require telephone-number based authentica- 517 tion, use of EAP, attribute-specific processing or addition of an 518 Authorize-Only message on the RADIUS server. This scheme allows for 519 accounting records to be generated on both the NAS and tunnel server 520 ends allowing for auditing. Also, in contrast to the previous scheme, 521 the tunnel endpoint does not need to have an account relationship with 522 the NAS owner. Thus this scheme is compatible with roaming. Disadvan- 523 tages are that unless LCP forwarding is used, LCP will need to be 524 renegotiated, and that dual authentications are required. 526 The use of dual authentication can be complex, since some clients do 527 not support it at all, and others only support only a subset of the 528 dual authentication combinations. Feasible combinations include 529 PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, 530 CHAP/EAP, EAP/CHAP, and EAP/EAP. Assuming that the required dual 531 authentication capabilities are supported, this scheme may be practi- 532 cally employed. 534 7. Telephone-number based authentication 536 7.1. Initiation sequence 538 In the case of telephone-number based authentication, a typical initi- 539 ation sequence looks like this: 541 Client and NAS: Call Connected 542 NAS to RADIUS Server: RADIUS Access-request 543 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 544 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 545 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 546 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 547 Client and Tunnel Server: PPP LCP negotiation 548 Client and Tunnel Server: PPP authentication 549 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 550 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 551 Client and Tunnel Server: NCP negotiation 552 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 553 RADIUS Server to NAS: RADIUS Accounting-Response 554 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 555 with Acct-Status-Type=Start (Optional) 556 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 558 The process begins with an incoming call to the NAS. If configured for 559 telephone-number based authentication, the NAS MUST send a RADIUS 560 Access-Request containing the Calling-Station-Id and the Called-Sta- 561 tion-Id attributes. The RADIUS server will then respond with a RADIUS 562 Access-Accept or Access-Reject. 564 The NAS MUST NOT begin PPP authentication before bringing up the tun- 565 nel. If timing permits, the NAS MAY bring up the tunnel prior to 566 beginning LCP negotiation with the client. If this is done, then LCP 567 will not need to be renegotiated between the client and tunnel server. 569 If the initial telephone-number based authentication is unsuccessful, 570 the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS 571 MUST send an LCP-Terminate and disconnect the user. 573 In the case where tunnel attributes are included in the RADIUS Access- 574 Accept, and a PPTP/L2TP tunnel is indicated, the NAS will now bring up 575 a control connection if none existed before. The control connection 576 will be of the type indicated by Tunnel-Type, over the medium indi- 577 cated by Tunnel-Medium-Type, to the tunnel server indicated by Tunnel- 578 Server-Endpoint. This is accomplished by sending a PPTP/L2TP Start- 579 Control-Connection-Request message to the tunnel server. The tunnel 580 server will then with a PPTP/L2TP Start-Control-Connection-Reply. If 581 this message indicates an error, or if the control connection is ter- 582 minated at any future time, then the NAS MUST send an LCP-Terminate 583 and disconnect the user. 585 The NAS will then proceed to send a PPTP/L2TP Incoming-Call-Request 586 message to the tunnel server. Among other things, this message will 587 contain the Call Serial Number, which along with the NAS-IP-Address 588 and Tunnel-Server-Endpoint is used to uniquely identify the call. The 589 tunnel server will reply with a PPTP/L2TP Incoming-Call-Reply message. 590 If this message indicates an error, then the NAS MUST send an LCP-Ter- 591 minate and disconnect the user. If no error is indicated, the NAS then 592 replies with a PPTP/L2TP Incoming-Call-Connected message. 594 At this point, data MAY begin to flow through the tunnel. If LCP nego- 595 tiation had been begun between the NAS and the client, the client and 596 tunnel server MAY now renegotiate LCP and begin PPP authentication; 597 otherwise, the client and tunnel server will negotiate LCP for the 598 first time, and then move on to PPP authentication. 600 If a renegotiation is required, at the time that the renegotiation 601 begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP 602 negotiation, and the client and NAS MUST NOT have begun NCP negotia- 603 tion. Rather than sending an LCP CONFACK, the NAS will instead send an 604 LCP DOWN message. The Client MAY then renegotiate LCP, and from that 605 point forward, all PPP packets originated from the client will be 606 encapsulated and sent to the tunnel server. When LCP re-negotiation 607 has been concluded, the NCP phase will begin, and the tunnel server 608 will assign an address to the client. 610 If L2TP is being used as the tunnel protocol, and LCP renegotiation is 611 required, the NAS MAY in its initial setup notification include a copy 612 of the LCP CONFACKs sent in each direction which completed LCP negoti- 613 ation. The tunnel server MAY then use this information to avoid an 614 additional LCP negotiation. With L2TP, the initial setup notification 615 can also include the authentication information required to allow the 616 tunnel server to authenticate the user and decide to accept or decline 617 the connection. However, in telephone-number based authentication, PPP 618 authentication MUST NOT occur prior to the NAS bringing up the tunnel. 619 As a result, L2TP authentication forwarding MUST NOT be employed. 621 In performing the PPP authentication, the tunnel server can access its 622 own user database, or it MAY send a RADIUS Access-Request. The latter 623 approach is useful in cases where authentication forwarding is 624 enabled, such as with roaming or shared use networks. In this case, 625 the RADIUS and tunnel servers are under the same administration and 626 are typically located close together, possibly on the same LAN. 628 Therefore having the tunnel server act as a RADIUS client provides for 629 unified user administration. Other methods are also available, such as 630 use of LDAP, described in [12], by both the tunnel and RADIUS servers. 631 Note that the tunnel server's RADIUS Access-Request is typically sent 632 directly to the local RADIUS server rather than being forwarded via 633 proxy. 635 After the tunnel has been brought up, the NAS and tunnel server MAY 636 start accounting. In the case of the NAS, this is done by sending a 637 RADIUS Accounting-Request packet with Acct-Status-Type=Start to a 638 RADIUS server. The Accounting-Request packet MUST include the follow- 639 ing attributes: Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client- 640 Endpoint, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection-Id. The 641 Accounting-Request packet MAY also include the Calling-Station-Id and 642 Called-Station-Id attributes. 644 The tunnel server can produce its own accounting records, or it MAY 645 send a RADIUS Accounting-Request packet with Acct-Status-Type=Start to 646 a local RADIUS server. In the latter case, the RADIUS Accounting- 647 Request packet MUST contain the following attributes: Tunnel-Type, 648 Tunnel-Medium-Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-End- 649 point, and Acct-Tunnel-Connection-Id. 651 The interactions involved in initiation of a compulsory tunnel with 652 telephone-number based authentication are summarized below. In order 653 to simplify the diagram that follows, we have left out the client. 654 However, it is understood that the client participates via PPP negoti- 655 ation, authentication and subsequent data interchange with the Tunnel 656 Server. 658 INITIATION SEQUENCE 660 NAS Tunnel Server RADIUS Server 661 --- ------------- ------------- 662 Call connected 663 Send RADIUS 664 Access-Request 665 with Called-Station-Id, 666 and/or Calling-Station-Id 667 LCP starts 668 IF authentication 669 succeeds 670 Send ACK with 671 Tunnel-Type, 672 Tunnel-Medium-Type, 673 Tunnel-Server-Endpoint, 674 ELSE Send NAK 675 IF NAK DISCONNECT 676 ELSE 677 IF no control 678 connection exists 679 Send 680 Start-Control-Connection-Request 681 to Tunnel Server 682 Send 683 Start-Control-Connection-Reply 684 to NAS 685 ENDIF 687 Send 688 Incoming-Call-Request 689 message to Tunnel Server 690 Send Incoming-Call-Reply 691 to NAS 692 Send 693 Incoming-Call-Connected 694 message to Tunnel Server 696 Send data through the tunnel 697 Re-negotiate LCP, 698 authenticate user, 699 bring up IPCP, 700 start accounting 701 Send RADIUS 702 Accounting-Request with 703 Acct-Status-Type=Start 704 (optional) 705 Send 706 RADIUS 707 Accounting-Response 708 Send a RADIUS 709 Accounting-Request message 710 with Acct-Status-Type=Start 711 containing 712 Tunnel-Type, Tunnel-Medium-Type, 713 Acct-Tunnel-Client-Endpoint, 714 Tunnel-Server-Endpoint, 715 Acct-Tunnel-Connection-Id, 716 Calling-Station-Id, 717 Called-Station-Id. 718 Send 719 RADIUS 720 Accounting-Response 722 ENDIF 724 7.2. EAP support 726 It is expected that the Extensible Authentication Protocol (EAP) 727 described in [13] will frequently be used along with telephone number- 728 based authentication and tunneling in order to provide additional 729 security. In this case, EAP authentication may be used in the tunnel 730 authentication only, using EAP code present on the NAS, or via support 731 of EAP within RADIUS described in [11]. In this case, the initiation 732 sequence will look like this: 734 Client and NAS: Call Connected 735 Client and NAS: PPP LCP negotiation 736 NAS to RADIUS Server: RADIUS Access-Request 737 RADIUS server to NAS: RADIUS Access-Reply/Tunnel attributes 738 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 739 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 740 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 741 Client and Tunnel Server: PPP LCP re-negotiation (optional) 742 Client and Tunnel Server: EAP authentication 743 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start 744 RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message 745 Tunnel Server to Client: EAP-Request 746 Client to Tunnel Server: EAP-Response 747 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message 748 RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success 749 Client and Tunnel Server: NCP negotiation 750 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 751 RADIUS Server to NAS: RADIUS Accounting-Response 752 Tunnel Server to RADIUS Server: RADIUS Accounting-Request with 753 Acct-Status-Type=Start (Optional) 754 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 756 8. Single authentication 758 8.1. Initiation sequence 760 In the case of a single authentication compulsory tunnel, a typical 761 initiation sequence looks like this: 763 Client and NAS: Call Connected 764 Client and NAS: PPP LCP negotiation 765 Client and NAS: EAP authentication 766 NAS to RADIUS Server: RADIUS Access-request 767 RADIUS server to NAS: RADIUS Access-Challenge/Access-Reject 768 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 769 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 770 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 771 Client and Tunnel Server: PPP LCP re-negotiation (optional) 772 Client and Tunnel Server: EAP authentication 773 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 774 RADIUS server to Tunnel Server: RADIUS Access-Challenge/Access-Reject 775 Client and Tunnel Server: NCP negotiation 776 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 777 RADIUS Server to NAS: RADIUS Accounting-Response 778 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 779 with Acct-Status-Type=Start (Optional) 780 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 782 The process begins with an incoming call to the NAS, and the PPP LCP 783 negotiation between the Client and NAS. At this point, the NAS must 784 offer EAP, and the Client must accept if the negotiation is to pro- 785 ceed. If the Client is incapable of authenticating via EAP, then the 786 NAS MUST send an LCP-Terminate and disconnect the user. 788 The NAS will now typically send an EAP-Request/Identity packet to the 789 Client, and the client will respond with an EAP-Response/MyId packet. 790 The NAS now sends an Access-Request/EAP-Message/EAP-Response/MyId 791 packet to the RADIUS server, which responds with an Access-Challenge 792 or an Access-Reject. 794 If single-authentication tunneling is to be carried out, the Access- 795 Challenge packet MUST contain the Tunnel-Type, Tunnel-Medium-Type, and 796 Tunnel-Server-Endpoint Attributes. The presence of tunneling 797 attributes in the Access-Challenge indicates to the NAS that a tunnel 798 MUST be brought up prior to continuation of the EAP conversation. As a 799 result, if the Access-Challenge contains an EAP-Message attribute, 800 then the NAS MUST NOT send the EAP-Request encapsulated in the EAP- 801 Message prior to bringing up the tunnel. Since after the tunnel is 802 brought up LCP will be renegotiated, EAP-Message attributes are effec- 803 tively ignored whenever the Access-Challenge also contains tunnel 804 attributes. 806 In the case where a PPTP/L2TP tunnel is indicated, the NAS will now 807 bring up a control connection if none existed before, and the NAS and 808 tunnel server will bring up the call. At this point, data MAY begin to 809 flow through the tunnel. The client and tunnel server MAY now renego- 810 tiate LCP and will complete PPP authentication. 812 At the time that the renegotiation begins, the NAS SHOULD NOT have 813 sent an LCP CONFACK completing LCP negotiation, and the client and NAS 814 MUST NOT have begun NCP negotiation. Rather than sending an LCP CON- 815 FACK, the NAS will instead send an LCP DOWN message. The Client MAY 816 then renegotiate LCP, and from that point forward, all PPP packets 817 originated from the client will be encapsulated and sent to the tunnel 818 server. In single authentication compulsory tunneling, L2TP authenti- 819 cation forwarding MUST NOT be employed. 821 If the tunnel server and NAS both are using the same RADIUS server, 822 the RADIUS server will respond to the tunnel server's Access-Request 823 with an Access-Challenge packet containing tunnel attributes and an 824 EAP-Message attribute, as before. On receiving the Access-Challenge 825 including tunnel attributes, the tunnel server will check whether the 826 tunnel matches the attributes returned by the RADIUS server; if so, 827 the tunnel attributes will be ignored, and the EAP-Request specified 828 in the EAP-Message attribute will be sent to the Client. If the tunnel 829 attributes do not match, then the tunnel server MUST disconnect the 830 call. 832 When LCP re-negotiation has been concluded, the NCP phase will begin, 833 and the tunnel server will assign an address to the client. 835 In performing the PPP authentication, the tunnel server can access its 836 own user database, or it MAY send a RADIUS Access-Request. After the 837 tunnel has been brought up, the NAS and tunnel server MAY start 838 accounting. 840 The interactions involved in initiation of a compulsory tunnel with 841 single authentication are summarized below. 843 INITIATION SEQUENCE 845 NAS Tunnel Server RADIUS Server 846 --- ------------- ------------- 847 Call accepted 848 LCP starts 849 EAP authentication 850 phase starts 851 Send RADIUS 852 Access-Request 853 with EAP-Message/MyId 854 attribute 855 IF MyId is known, 856 send RADIUS 857 Access-Challenge with 858 Tunnel-Type, 859 Tunnel-Medium-Type, 860 Tunnel-Server-Endpoint, 861 EAP-Message (optional) 862 ELSE Send NAK 863 IF NAK DISCONNECT 864 ELSE 865 IF no control 866 connection exists 867 Send 868 Start-Control-Connection-Request 869 to Tunnel Server 870 Send 871 Start-Control-Connection-Reply 872 to NAS 873 ENDIF 875 Send 876 Incoming-Call-Request 877 message to Tunnel Server 878 Send Incoming-Call-Reply 879 to NAS 880 Send 881 Incoming-Call-Connected 882 message to Tunnel Server 884 Send data through the tunnel 885 Re-negotiate LCP, 886 authenticate user via EAP, 887 bring up IPCP, 888 start accounting 889 Send RADIUS 890 Accounting-Request with 891 Acct-Status-Type=Start 892 (optional) 893 Send 894 RADIUS 895 Accounting-Response 896 Send a RADIUS 897 Accounting-Request message 898 with Acct-Status-Type=Start 899 containing 900 Tunnel-Type, Tunnel-Medium-Type, 901 Acct-Tunnel-Client-Endpoint, 902 Tunnel-Server-Endpoint, and 903 Acct-Tunnel-Connection-Id. 904 Send 905 RADIUS 906 Accounting-Response 908 ENDIF 910 9. Dual authentication 912 9.1. Initiation sequence 914 In the case of a dual authentication, a typical initiation sequence 915 looks like this: 917 Client and NAS: PPP LCP negotiation 918 Client and NAS: PPP authentication 919 NAS to RADIUS Server: RADIUS Access-request 920 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 921 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 922 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 923 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 924 Client and Tunnel Server: PPP LCP re-negotiation (optional) 925 Client and Tunnel Server: PPP authentication 926 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 927 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 928 Client and Tunnel Server: NCP negotiation 929 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 930 RADIUS Server to NAS: RADIUS Accounting-Response 931 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 932 with Acct-Status-Type=Start (Optional) 933 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 935 The process begins with an incoming call to the NAS. The client and 936 NAS then begin LCP negotiation. Subsequently the PPP authentication 937 phase starts, and the NAS sends a RADIUS Access-Request message to the 938 RADIUS server. If the authentication is successful, the RADIUS server 939 responds with a RADIUS Access-Accept. For users requiring mandatory 940 tunneling, the Access-Accept MUST contain the the Tunnel-Type, Tunnel- 941 Medium-Type, and Tunnel-Server-Endpoint Attributes. 943 In the case where a PPTP/L2TP tunnel is indicated, the NAS will now 944 bring up a control connection if none existed before, and the NAS and 945 tunnel server will bring up the call. At this point, data MAY begin to 946 flow through the tunnel. The client and tunnel server MAY now renego- 947 tiate LCP and go through another round of PPP authentication. At the 948 time that this renegotiation begins, the NAS SHOULD NOT have sent an 949 LCP CONFACK completing LCP negotiation, and the client and NAS MUST 950 NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, 951 the NAS will instead send an LCP DOWN message. The Client MAY then 952 renegotiate LCP, and from that point forward, all PPP packets origi- 953 nated from the client will be encapsulated and sent to the tunnel 954 server. When LCP re-negotiation has been concluded, the NCP phase 955 will begin, and the tunnel server will assign an address to the 956 client. 958 If L2TP is being used as the tunnel protocol, the NAS MAY in its ini- 959 tial setup notification include a copy of the LCP CONFACKs sent in 960 each direction which completed LCP negotiation. The tunnel server MAY 961 then use this information to avoid an additional LCP negotiation. With 962 L2TP, the initial setup notification can also include the authentica- 963 tion information required to allow the tunnel server to authenticate 964 the user and decide to accept or decline the connection. However, this 965 facility creates a vulnerability to replay attacks, and can create 966 problems in the case where the NAS and tunnel server authenticate 967 against different RADIUS servers. As a result, where user-based tun- 968 neling via RADIUS is implemented, L2TP authentication forwarding 969 SHOULD NOT be employed. 971 In performing the PPP authentication, the tunnel server can access its 972 own user database, or it MAY send a RADIUS Access-Request. After the 973 tunnel has been brought up, the NAS and tunnel server MAY start 974 accounting. 976 The interactions involved in initiation of a compulsory tunnel with 977 dual authentication are summarized below. 979 INITIATION SEQUENCE 981 NAS Tunnel Server RADIUS Server 982 --- ------------- ------------- 983 Call accepted 984 LCP starts 985 PPP authentication 986 phase starts 987 Send RADIUS 988 Access-Request 989 with username and 990 authentication data 991 IF authentication 992 succeeds 993 Send ACK with 994 Tunnel-Type, 995 Tunnel-Medium-Type, 996 Tunnel-Server-Endpoint, 997 ELSE Send NAK 998 IF NAK DISCONNECT 999 ELSE 1000 IF no control 1001 connection exists 1002 Send 1003 Start-Control-Connection-Request 1004 to Tunnel Server 1005 Send 1006 Start-Control-Connection-Reply 1007 to NAS 1008 ENDIF 1010 Send 1011 Incoming-Call-Request 1012 message to Tunnel Server 1013 Send Incoming-Call-Reply 1014 to NAS 1015 Send 1016 Incoming-Call-Connected 1017 message to Tunnel Server 1019 Send data through the tunnel 1020 Re-negotiate LCP, 1021 authenticate user, 1022 bring up IPCP, 1023 start accounting 1024 Send RADIUS 1025 Accounting-Request with 1026 Acct-Status-Type=Start 1027 (optional) 1028 Send 1029 RADIUS 1030 Accounting-Response 1031 Send a RADIUS 1032 Accounting-Request message 1033 with Acct-Status-Type=Start 1034 containing 1035 Tunnel-Type, Tunnel-Medium-Type, 1036 Acct-Tunnel-Client-Endpoint, 1037 Tunnel-Server-Endpoint, and 1038 Acct-Tunnel-Connection-Id. 1039 Send 1040 RADIUS 1041 Accounting-Response 1043 ENDIF 1044 9.2. EAP support 1046 It is expected that the Extensible Authentication Protocol (EAP) 1047 described in [13] will frequently be used along with tunneling in 1048 order to provide additional security. EAP authentication may be used 1049 in the initial NAS authentication, in the tunnel authentication, or 1050 both, with support of EAP within RADIUS described in [11]. In the 1051 case where EAP authentication is carried out between the NAS and 1052 client, the initiation sequence will look like this: 1054 Client and NAS: PPP LCP negotiation 1055 Client and NAS: EAP Authentication 1056 NAS to RADIUS Server: RADIUS Access-Request/EAP-start 1057 RADIUS server to NAS: RADIUS Access-Challenge/EAP-Message 1058 NAS to Client: EAP-Request 1059 Client to NAS: EAP-Response 1060 NAS to RADIUS Server: RADIUS Access-Request/EAP-Message 1061 RADIUS server to NAS: RADIUS Access-Accept/EAP-Message/EAP-Success 1062 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 1063 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 1064 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 1065 Client and Tunnel Server: PPP LCP re-negotiation (optional) 1066 Client and Tunnel Server: PPP authentication 1067 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 1068 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 1069 Client and Tunnel Server: NCP negotiation 1070 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 1071 RADIUS Server to NAS: RADIUS Accounting-Response 1072 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 1073 With Acct-Status-Type=Start(Optional) 1074 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 1076 In the case where EAP authentication is carried out between the client 1077 and tunnel server, the initiation sequence will look like this: 1079 Client and NAS: PPP LCP negotiation 1080 Client and NAS: PPP authentication 1081 NAS to RADIUS Server: RADIUS Access-request 1082 RADIUS server to NAS: RADIUS Access-Accept 1083 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 1084 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 1085 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 1086 Client and Tunnel Server: PPP LCP re-negotiation (optional) 1087 Client and Tunnel Server: EAP authentication 1088 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start 1089 RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message 1090 Tunnel Server to Client: EAP-Request 1091 Client to Tunnel Server: EAP-Response 1092 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message 1093 RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success 1094 Client and Tunnel Server: NCP negotiation 1095 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 1096 RADIUS Server to NAS: RADIUS Accounting-Response 1097 Tunnel Server to RADIUS Server: RADIUS Accounting-Request with 1098 Acct-Status-Type=Start (Optional) 1099 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 1101 For the negotiations described above to succeed, the client must be 1102 capable of renegotiating EAP with the tunnel server after an initial 1103 authentication with the NAS. 1105 10. Termination sequence 1107 The tear down of a compulsory tunnel involves an interaction between 1108 the client, NAS, Tunnel Server, and RADIUS Accounting server. This 1109 interaction is virtually identical regardless of whether telephone- 1110 number based authentication, single authentication, or dual authenti- 1111 cation is being used. In any of the cases, the following events occur: 1113 Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional) 1114 NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify 1115 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Stop 1116 RADIUS Server to NAS: RADIUS Accounting-Response 1117 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 1118 with Acct-Status-Type=Stop(Optional) 1119 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 1121 Tunnel termination can occur due to a client request (PPP termina- 1122 tion), a tunnel server request (Call-Clear-Request), or a line problem 1123 (call disconnect). 1125 In the case of a client-requested termination, the tunnel server MUST 1126 terminate the PPP session. The tunnel server MUST subsequently send a 1127 Call-Clear-Request to the NAS. The NAS MUST then send a Call-Discon- 1128 nect-Notify message to the tunnel server, and will disconnect the 1129 call. 1131 The NAS MUST also respond with a Call-Disconnect-Notify message and 1132 disconnection if it receives a Call-Clear-Request from the tunnel 1133 server without a client-requested termination. 1135 In the case of a line problem or user hangup, the NAS MUST send a 1136 Call-Disconnect-Notify to the tunnel server. Both sides will then tear 1137 down the call. 1139 After call tear down is complete, if RADIUS accounting is being used 1140 then the NAS MUST send a RADIUS Accounting-Request with Acct-Status- 1141 Type=Stop packet to a RADIUS accounting server. The Accounting- 1142 Request packet MUST include the following attributes: Tunnel-Type, 1143 Tunnel-Medium-Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-End- 1144 point, and Acct-Tunnel-Connection-Id. 1146 The tunnel server MAY produce its own accounting records, or it MAY 1147 use RADIUS accounting. If RADIUS accounting is being used then the 1148 tunnel server MUST send a RADIUS Accounting-Request with Acct-Status- 1149 Type=Stop to a RADIUS accounting server. The Accounting-Request packet 1150 MUST contain the following attributes: Tunnel-Type, Tunnel-Medium- 1151 Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Acct- 1152 Tunnel-Connection-Id. 1154 The interactions involved in termination of a compulsory tunnel are 1155 summarized below. In order to simplify the diagram that follows, we 1156 have left out the client. However, it is understood that the client 1157 MAY participate via PPP termination and disconnection. 1159 TERMINATION SEQUENCE 1161 NAS Tunnel Server RADIUS Server 1162 --- ------------- ------------- 1163 IF user disconnected 1164 send 1165 Call-Disconnect-Notify 1166 message to tunnel server 1167 Tear down the call 1168 stop accounting 1169 Send RADIUS 1170 Accounting-Request with 1171 Acct-Status-Type=Stop 1172 (optional) 1173 Send RADIUS 1174 Accounting-Response 1175 ELSE IF client requests 1176 termination 1177 send 1178 Call-Clear-Request 1179 to the NAS 1180 Send 1181 Call-Disconnect-Notify 1182 message to tunnel server 1183 Disconnect the user 1184 Tear down the call 1185 stop accounting 1186 Send RADIUS 1187 Accounting-Request with 1188 Acct-Status-Type=Stop 1189 (optional) 1190 Send RADIUS 1191 Accounting-Response 1193 Send a RADIUS 1194 Accounting-Request message 1195 with Acct-Status-Type=Stop 1196 containing 1197 Tunnel-Type, Tunnel-Medium-Type, 1198 Acct-Tunnel-Client-Endpoint, 1199 Tunnel-Server-Endpoint, and 1200 Acct-Tunnel-Connection-Id. 1201 Send RADIUS 1202 Accounting-Response 1204 ENDIF 1205 11. Use of distinct RADIUS servers 1207 In the case that the NAS and the tunnel server are using distinct 1208 RADIUS servers, some interesting cases can arise in the provisioning 1209 of compulsory tunnels. 1211 11.1. Distinct userIDs 1213 If distinct RADIUS servers are being used, it is likely that distinct 1214 userID/password pairs will be required to complete the RADIUS and tun- 1215 nel authentications. One pair will be used in the initial PPP authen- 1216 tication with the NAS, and the second pair will be used for the tunnel 1217 authentication. 1219 However, in order to provide maximum ease of use in the case where the 1220 userID/password pairs are identical, tunnel clients typically attempt 1221 authentication with the same userID/password pair as was used in the 1222 initial PPP negotiation. Only after this fails do they prompt the user 1223 for the second pair. 1225 In this case, tunnel client implementations SHOULD take care not to 1226 put up error messages indicating a bad password. Instead a dialog 1227 SHOULD be presented requesting the tunnel userID/password combination. 1229 In the case where smart cards are being used for both authentications, 1230 the tunnel client MUST NOT attempt to present the token used in the 1231 first authentication during the second authentication, since these 1232 will never be identical. Instead the user SHOULD be prompted to enter 1233 the second token. 1235 The same issue arises in L2TP if the NAS attempts to forward authenti- 1236 cation information to the tunnel server in the initial setup notifica- 1237 tion. Since the userID/password pair used for tunnel authentication is 1238 different from that used to authenticate against the NAS, forwarding 1239 authentication information in this manner will cause the tunnel 1240 authentication to fail. As a result, where user-based tunneling via 1241 RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be 1242 employed. 1244 11.2. Multilink PPP issues 1246 It is possible for the two RADIUS servers to return different Port- 1247 Limit attributes. For example, it is conceivable that the NAS RADIUS 1248 server will only grant use of a single channel, while the tunnel 1249 RADIUS server will grant more than one channel. In this case, the cor- 1250 rect behavior is for the tunnel client to open a connection to another 1251 NAS in order to bring up a multilink bundle on the tunnel server. The 1252 client MUST NOT indicate to the NAS that this additional link is being 1253 brought up as part of a multilink bundle; this will only be indicated 1254 in the subsequent negotiation with the tunnel server. 1256 It is also conceivable that the NAS RADIUS server will allow the 1257 client to bring up multiple channels, but that the tunnel RADIUS 1258 server will allow fewer channels than the NAS RADIUS server. In this 1259 case, the client should terminate use of the excess channels. 1261 12. UserID Issues 1263 In the provisioning of roaming and shared use networks, one of the 1264 requirements is to be able to route the authentication request to the 1265 user's home RADIUS server. This authentication routing is accomplished 1266 based on the userID submitted by the user to the NAS in the initial 1267 PPP authentication. The userID is subsequently relayed by the NAS to 1268 the RADIUS server in the User-Name attribute, as part of the RADIUS 1269 Access-Request. 1271 Similarly, references [5] and [6] refer to use of the userID in deter- 1272 mining the tunnel endpoint. However, since none of these references 1273 provide guidelines for how RADIUS or tunnel routing is to be accom- 1274 plished, the possibility of conflicting interpretations exists. 1276 12.1. UserID convergence in user-based tunneling 1278 The use of RADIUS in provisioning of compulsory tunneling relieves the 1279 userID from having to do double duty. Rather than being used both for 1280 routing of the RADIUS authentication/authorization request as well for 1281 determination of the tunnel endpoint, the userID is now used solely 1282 for routing of RADIUS authentication/authorization requests. The Tun- 1283 nel-Server-Endpoint attribute returned in the RADIUS Access-Response 1284 Is then used to determine the tunnel endpoint. 1286 Since the framework described in this document allows both ISPs and 1287 tunnel users to authenticate users as well as to account for resources 1288 consumed by them, and provides for maintenance of two distinct 1289 userID/password pairs, this scheme provides a high degree of flexibil- 1290 ity. Where RADIUS proxies and tunneling are employed, it is possible 1291 to allow the user to authenticate with a single userID/password pair 1292 at both the NAS and the tunnel endpoint. This is accomplished by rout- 1293 ing the NAS RADIUS Access-Request to the same RADIUS server used by 1294 the tunnel server. 1296 As described in [8], the recommended form for the user ID is 1297 userID@realm, i.e. fred@bigco.com. 1299 13. Acknowledgements 1301 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions 1302 of this problem space, and to Allan Rubens of Ascend and Bertrand 1303 Buclin of AT&T Labs Europe for his comments on this document. 1305 14. References 1307 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 1308 Implementations." Work in progress, draft-ietf-roamops-imprev-04.txt, 1309 Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997. 1311 [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft 1312 (work in progress), draft-ietf-roamops-roamreq-05.txt, Microsoft, 1313 July, 1997. 1315 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 1316 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 1317 Daydreamer, April, 1997. 1319 [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April, 1320 1997. 1322 [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. 1323 Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." ." 1324 Internet draft (work in progress), draft-ietf-pppext-l2tp-04.txt, 1325 Ascend Communications, Microsoft, Copper Mountain Networks, U.S. 1326 Robotics, June, 1997. 1328 [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. 1329 "Point-to-Point Tunneling Protocol -- PPTP." ." Internet draft (work 1330 in progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications, 1331 Microsoft, Copper Mountain Networks, U.S. Robotics, July, 1997. 1333 [7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter- 1334 net draft (work in progress), draft-ietf-radius-tunnel-auth-02.txt, 1335 Microsoft, July, 1997. 1337 [8] B. Aboba, M. A. Beadles. "The Network Access Identifier." Inter- 1338 net draft (work in progress), draft-ietf-roamops-nai-06.txt, 1339 Microsoft, CompuServe, July, 1997. 1341 [9] S. Bradner. "Key words for use in RFCs to Indicate Requirement 1342 Levels." RFC 2119, Harvard University, March, 1997. 1344 [10] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, 1345 draft-ietf-radius-ext-00.txt, Livingston, January, 1997. 1347 [11] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication 1348 Protocol Support in RADIUS." Internet draft (work in progress), draft- 1349 ietf-radius-eap-02.txt, US Robotics Access Corp., Merit Network, 1350 Microsoft, May, 1997. 1352 [12] M. Wahl, T. Howes, S. Kille. "Lightweight Directory Access Pro- 1353 tocol (v3)." ." Internet draft (work in progress), draft-ietf-asid- 1354 ldapv3-protocol-04.txt, Critical Angle Inc., Netscape, Isode Limited, 1355 March, 1997. 1357 [13] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 1358 Protocol (EAP)." ." Internet draft (work in progress), draft-ietf- 1359 pppext-eap-auth-02.txt, Merit Network, Inc., June, 1996. 1361 15. Authors' Addresses 1363 Bernard Aboba 1364 Microsoft Corporation 1365 One Microsoft Way 1366 Redmond, WA 98052 1368 Phone: 425-936-6605 1369 EMail: bernarda@microsoft.com 1371 Glen Zorn 1372 Microsoft Corporation 1373 One Microsoft Way 1374 Redmond, WA 98052 1376 Phone: 425-703-1559 1377 EMail: glennz@microsoft.com