idnits 2.17.1 draft-ietf-radius-tunnel-imp-02.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-27) 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 26 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 395 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 678 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: '... 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 adjec...' RFC 2119 keyword, line 117: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 120: '... SHOULD This word, or the adje...' (92 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (390 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 (11 July 1997) is 9787 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 1328 looks like a reference -- Missing reference section? '4' on line 1332 looks like a reference -- Missing reference section? '9' on line 1354 looks like a reference -- Missing reference section? '7' on line 1346 looks like a reference -- Missing reference section? '6' on line 1341 looks like a reference -- Missing reference section? '10' on line 1357 looks like a reference -- Missing reference section? '11' on line 1360 looks like a reference -- Missing reference section? '12' on line 1365 looks like a reference -- Missing reference section? '13' on line 1370 looks like a reference -- Missing reference section? '5' on line 1335 looks like a reference -- Missing reference section? '8' on line 1350 looks like a reference -- Missing reference section? '1' on line 1320 looks like a reference -- Missing reference section? '2' on line 1324 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. -------------------------------------------------------------------------------- 1 RADIUS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Standards Track Glen Zorn 4 Microsoft 5 11 July 1997 7 Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as and expires January 1, 1998. Please 28 send comments to the authors. 30 2. Abstract 32 This document discusses implementation issues arising in the provi- 33 sioning of compulsory tunneling in dial-up networks using the PPTP and 34 L2TP protocols. This provisioning can be accomplished via the inte- 35 gration of RADIUS and tunneling protocols. Implementation issues 36 encountered with other tunneling protocols are left to separate docu- 37 ments. 39 3. Terminology 41 Voluntary Tunneling 42 In compulsory tunneling, a tunnel is created without any 43 action from the user and without allowing the user any 44 choice. 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. 156 An implementation that satisfies all the MUST, MUST NOT, SHOULD and 157 SHOULD NOT requirements for its protocols is said to be "uncondition- 158 ally compliant"; one that satisfies all the MUST and MUST NOT require- 159 ments but not all the SHOULD or SHOULD NOT requirements for its proto- 160 cols is said to be "conditionally compliant." 162 5. Introduction 164 Many applications of tunneling protocols involve dial-up network 165 access. Some, such as the provisioning of secure access to corporate 166 intranets via the Internet, are characterized by voluntary tunneling: 167 the tunnel is created at the request of the user for a specific pur- 168 pose. Other applications involve compulsory tunneling: the tunnel is 169 created without any action from the user and without allowing the user 170 any choice. 172 Examples of applications that might be implemented using compulsory 173 tunnels are Internet software upgrade servers, software registration 174 servers and banking services. These are all services which, without 175 compulsory tunneling, would probably be provided using dedicated net- 176 works or at least dedicated network access servers (NAS), since they 177 are characterized by the need to limit user access to specific hosts. 179 Given the existence of widespread support for compulsory tunneling, 180 however, these types of services could be accessed via any Internet 181 service provider (ISP). The most popular means of authorizing dial-up 182 network users today is through the RADIUS protocol. The use of 183 RADIUS allows the dial-up users' authorization and authentication data 184 to be maintained in a central location, rather than on each NAS. It 185 makes sense to use RADIUS to centrally administer compulsory tun- 186 neling, since RADIUS is widely deployed and was designed to 187 carry this type of information. New RADIUS attributes are needed to 188 carry the tunneling information from the RADIUS server to the NAS 189 and to transfer accounting data from the NAS to the RADIUS accounting 190 server; those attributes are defined in [7]. 192 5.1. Tunneling attributes 194 As described in [7], provisioning of compulsory tunneling with RADIUS 195 requires no new RADIUS messages, and implementation of six new RADIUS 196 attributes: Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client-End- 197 point, Tunnel-Server-Endpoint, Acct-Tunnel-Connection-Id, and Tunnel- 198 Password. 200 The Tunnel-Type attribute indicates the tunneling protocol(s) to be 201 used (PPTP, L2F, L2TP, ATMP, VTP, IPSEC AH, IP-IP). It MAY be included 202 in Access-Request, Access-Accept, and Access-Challenge packets. 204 The Tunnel-Medium-Type Attribute indicates which transport medium to 205 use (IP, X.25, ATM, Frame Relay) when creating a tunnel for those pro- 206 tocols (such as L2TP) that can operate over multiple transports. 207 It MAY be included in in Access-Request, Access-Accept, and Access- 208 Challenge packets. 210 Acct-Tunnel-Client-Endpoint contains the address of the NAS end of the 211 tunnel. It SHOULD be included in Accounting-Request packets which 212 contain Acct-Status-Type attributes with values of either Start or 213 Stop. This Attribute, along with the Tunnel-Server-Endpoint and 214 Acct-Tunnel-Connection-ID attributes, may be used to provide a glob- 215 ally unique means to identify a tunnel for accounting purposes. 217 Tunnel-Server-Endpoint indicates the address of the server end of the 218 tunnel. It SHOULD be included in Accounting-Request packets which 219 contain Acct-Status-Type attributes with values of either Start or 220 Stop. 222 Acct-Tunnel-Connection-ID indicates the identifier assigned to the 223 call. It SHOULD be included in Accounting-Request packets which 224 contain Acct-Status-Type attributes with values of either Start or 225 Stop. 227 The Tunnel-Password attribute may contain a key or password, which is 228 to be used with protocols such as L2TP which support authenticated 229 tunnels. It may only be included in an Access-Accept or Access- 230 Challenge packet. 232 Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS 233 server may be processed by one or more proxies prior to being received 234 by the NAS. In order to ensure that tunnel attributes arrive without 235 modification, intermediate RADIUS proxies forwarding the Access-Reply 236 MUST NOT modify tunnel attributes. If the RADIUS proxy does not sup- 237 port tunnel attributes, then it MUST send an Access-Reject to the NAS. 238 This is necessary to ensure that the user is only granted access if 239 the services requested by the RADIUS server can be provided. 241 Since RADIUS tunnel attributes are used for compulsory tunneling, 242 address assignment is handled by the tunnel server rather than the 243 NAS. As a result, if tunnel attributes are present, the NAS MUST 244 ignore any address assignment attributes sent by the RADIUS server. In 245 addition, the NAS and client MUST NOT begin NCP negotiation, since 246 this could create a time window in which the client will be capable of 247 sending packets to the transport network, which is not permitted under 248 compulsory tunneling. 250 5.2. Advantanges of RADIUS-based compulsory tunneling 252 The use of RADIUS in provisioning of compulsory tunnels has several 253 advantages. These include: 255 User-based tunneling 256 Auditing capabilities 257 Telephone-number based authentication and accounting 258 Single or dual authentication 260 5.2.1. User-based Tunneling 262 Current proposals for routing of tunnel requests include static tun- 263 neling, where all users are automatically tunneled to a given end- 264 point, and realm-based tunneling, where the tunnel endpoint is deter- 265 mined from the realm portion of the userID. User-based tunneling as 266 provided by integration of RADIUS and tunnel protocols offers signifi- 267 cant advantages over both of these approaches. 269 Static tunneling requires dedication of a NAS device to the purpose. 270 In the case of an ISP, this is undesirable because it requires them to 271 dedicate a NAS to tunneling service for a given corporate customer, 272 rather than allowing them to use existing NASes deployed in the field. 273 As a result static tunneling is likely to be costly for deployment of 274 a global service. 276 Realm-based tunneling assumes that all users within a given realm wish 277 to be treated the same way. This limits a corporation's flexibility in 278 managing the account rights of their users. For example, BIGCO may 279 desire to provide Janet with an account that allows access to both the 280 Internet and the intranet, with Janet's intranet access provided by a 281 tunnel server located in the engineering department. However BIGCO may 282 desire to provide Fred with an account that provides only access to 283 the intranet, with Fred's intranet access provided by a tunnel network 284 server located in the sales department. Such a situation cannot be 285 accommodated with realm-based tunneling. 287 On the other hand, user-based tunneling as enabled by the attributes 288 defined in [7] provides BIGCO with the flexibility to administer tun- 289 neling behavior on a per-user basis. When deployed in concert with 290 roaming, user-based tunneling offers corporations the ability to pro- 291 vide their users with access to the corporate Intranet on a global 292 basis. 294 5.3. Auditing Capabilities 296 The integration of RADIUS and tunnel protocols allows the ISP and the 297 corporation to synchronize their accounting activities so that each 298 side receives a record of the user's resource consumption. This pro- 299 vides the corporation with the means to audit ISP bills. 301 The Acct-Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID 302 attributes were introduced in [7] in order to support auditing. These 303 attributes are included within the RADIUS Accounting-Request packet 304 along with other attributes such as the User-Name and Tunnel-Server- 305 Endpoint. During accounting, the User-Name, Acct-Tunnel-Connection- 306 ID, Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes 307 uniquely identify the call. This allows the Accounting-Request sent by 308 the NAS to be reconciled with the corresponding Accounting-Request 309 sent by the tunnel server. 311 When implementing L2TP 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. In order to protect 314 against wrapping due to reboots or call volume, a 64-bit NTP timestamp 315 SHOULD be used as the Call-Serial Number. This feasible in L2TP since 316 the Call-Serial-Number string is of variable length. 318 When implementing PPTP compulsory tunneling based on RADIUS, the NAS 319 MUST transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID 320 attribute in the Accounting-Request packet. While [6] states that the 321 Call-Serial-Number SHOULD be unique, this is not required. In addi- 322 tion, no method for determining the Call-Serial-Number is specified, 323 which leaves open the possibility of wrapping after a reboot. 325 Since the Call-Serial-Number is a 16-bit value, the Call-Serial-Number 326 is not sufficient to distinguish a given call from all other calls 327 over an extended time period. For example, let us assume that the Call 328 Serial Number is assigned monotonically, and that the NAS in question 329 has 96 ports. If the NAS ports are kept continually busy and the aver- 330 age call is of 20 minutes duration, then the Call Serial Number will 331 wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.5 days. 333 In order to rectify this, it is recommended that another message be 334 added to PPTP so that the NAS could provide the tunnel server with an 335 Acct-Tunnel-Connection-ID unique over an extended time period. It is 336 recommended that a 64-bit NTP timestamp be used for this purpose. 338 5.4. Telephone-number based authentication and accounting 340 Using the Calling-Station-Id and Called-Station-Id RADIUS attributes, 341 authorization and subsequent tunnel attributes can be based on the 342 phone number originating the call, or the number being called. This 343 allows the RADIUS server to authorize users based on the calling phone 344 number (with or without a userID/password combination), or to select 345 the Tunnel-Type, Tunnel-Medium-Type, Tunnel-Server-Endpoint and Tun- 346 nel-Password attributes based on the Calling-Station-Id or Called-Sta- 347 tion-Id. Similarly, in PPTP/L2TP the tunnel server MAY choose to 348 reject or accept the call based on the Dialed Number and Dialing Num- 349 ber included in the PPTP/L2TP Incoming-Call-Request packet sent by the 350 NAS. 352 The use of RADIUS accounting by the NAS and/or the tunnel server 353 allows for accounting to take place based on the Calling-Station-Id 354 and Called-Station-Id. 356 5.5. Single or dual authentication 358 As described below, RADIUS-based compulsory tunneling can support a 359 variety of authentication configurations. These include single authen- 360 tication, where the user is authenticated at the tunnel server, or 361 dual authentication, where the user is authenticated at both the NAS 362 and the tunnel server. When single authentication is supported, a 363 variety of modes are possible, including telephone-number based 364 authentication described above, or EAP-based authentication. When 365 dual-authentication is used, a number of modes are available, includ- 366 ing dual CHAP authentications; CHAP/EAP authentication; 367 CHAP/PAP(token) authentication; and EAP/EAP authentication, using the 368 same EAP type for both authentications. 370 PAP/PAP, CHAP/PAP and EAP/PAP dual authentications SHOULD NOT be used, 371 since these combinations involve transmission of cleartext passwords 372 over the Internet. 374 6. Authentication alternatives in compulsory tunneling 376 There are several authentication alternatives for integration of 377 RADIUS and tunneling: 379 Authenticate at the NAS 380 Authenticate at the NAS, and forward the RADIUS reply 381 Authenticate at the tunnel network server 382 Authenticate at both the NAS and the tunnel network server 384 We discuss each of these alternatives in turn. 386 6.1. Authenticate at the NAS 388 With this approach, authentication and authorization (including tun- 389 neling information) occurs once, at the NAS. The advantages of this 390 approach are that it disallows network access for unauthorized NAS 391 users; and allows RADIUS accounting to be used at the NAS. Disadvan- 392 tages are that it requires that the tunnel network server trust the 393 NAS, since no user authentication occurs on the tunnel network server 394 end of the tunnel. Another disadvantage is that this does not allow 395 LCP parameters to be re-negotiated by the tunnel network server. Also, 396 due to the lack of user authentication, accounting cannot take place 397 at the tunnel network server with strong assurance that the correct 398 party is being billed. As a result, it does not appear that this 399 scheme can be practically employed. 401 6.2. Authenticate at the NAS, and forward the RADIUS reply 403 With this approach, authentication and authorization occurs once, at 404 the NAS end of the tunnel and the RADIUS reply is forwarded to the 405 tunnel network server. This approach disallows network access for 406 unauthorized NAS users; does not require trust between the NAS and 407 tunnel network server ends of the tunnel; and allows for RADIUS 408 accounting to be used at both ends of the tunnel. However, it also 409 requires that both ends share the same secret with the RADIUS server, 410 since that is the only way that the tunnel network server could check 411 the RADIUS reply. 413 In this approach, the tunnel network server MUST share secrets with 414 all the NASes and associated RADIUS servers, and there is no provision 415 for LCP renegotiation by the tunnel network server. Also, the tunnel 416 network server MUST know how to handle and verify RADIUS Access-Accept 417 messages. 419 While this scheme can be workable if the reply comes directly from a 420 RADIUS server, it would become unmanageable if a RADIUS proxy is 421 involved, since the reply would be authenticated using the secret 422 shared by the client and proxy, rather than the RADIUS server. As a 423 result, it does not appear that this scheme can be practically 424 employed. 426 6.3. Authenticate at the tunnel network server 428 In this scheme, authentication and authorization occurs once at the 429 tunnel network server. This requires that the NAS determine that the 430 user needs to be tunneled (through RADIUS or NAS configuration). Where 431 RADIUS is used, the determination can be made using one of the follow- 432 ing methods: 434 Telephone-number based authentication 435 User-Name 436 EAP Identity 438 6.3.1. Telephone-number based authentication 440 Where telephone-number based authentication is used, the Calling-Sta- 441 tion-Id or Called-Station-Id attributes included in the RADIUS Access- 442 Request are used to determine whether the call will be accepted or 443 rejected, and if accepted, where the user is to be tunneled. Where 444 telephone-number based authentication is used, the User-Name and User- 445 Password or CHAP-Password attributes need not be present. 447 In cases where telephone-number authentication may be employed, 448 accounting may be accomplished on the NAS side via the Calling-Sta- 449 tion-Id or Called-Station-Id, and on the tunnel server side, via the 450 userID. Thus this scheme is capable of providing both authentication 451 and accounting, and appears practical to implement. 453 6.3.2. User-Name 455 Where the User-Name attribute is present, RADIUS as defined in [3] 456 requires that either a CHAP-Password or User-Password attribute be 457 present in an Access-Request message, as well as requiring that the 458 password be non-empty. Thus, this scheme either requires attribute- 459 specific processing on the RADIUS server, or addition of an "Autho- 460 rize-Only" message. 462 In attribute-specific processing an attribute is used to signal tunnel 463 initiation. For example, tunnel attributes can be sent back if the 464 PAP password is empty (or "tunnel" or "L2TP"). Alternatively, a user 465 could prefix the userID with some special character ('*') if he wanted 466 to be tunneled. This particular solution does not support compulsory 467 tunneling. Another solution involves keying on the domain portion of 468 the userID; all users in domain X would be tunneled to address Y. 469 This proposal supports compulsory tunneling, but does not provide for 470 user-based tunneling. 472 An Authorize-Only message would not include a CHAP or PAP password; 473 nevertheless, in response the RADIUS server would return the attribute 474 list. In order to prevent password guessing attacks, an Authorize-Only 475 message would need to be authenticated via the RADIUS shared secret. 476 This could be accomplished via the Signature attribute described in 477 [10]. 479 Note that when either attribute-specific processing or an authorize- 480 only message is used, the tunnel network server would need to renego- 481 tiate LCP. Note also that in order for the NAS to start accounting on 482 the connection, it would need to use the identity claimed by the user 483 in authenticating to the tunnel network server, since it did not ver- 484 ify the identity via RADIUS. However, in order for that to be of any 485 use in accounting, the tunnel endpoint needs to have an account rela- 486 tionship with the NAS owner. Thus even if a user has an account with 487 the NAS owner, they cannot use this account for tunneling unless the 488 tunnel endpoint also has a business relationship with the NAS owner. 489 Without putting in place a public key infrastructure, it is not clear 490 how the NAS would be able to verify the existence of such a business 491 relationship in a scalable manner. Thus this approach nullifies many 492 of the benefits of roaming. Due to these difficulties, it does not 493 appear that this scheme can be practically employed. 495 6.3.3. EAP Identity 497 Where EAP is used as described in [11], the NAS may include an EAP- 498 Message/Identity attribute in the RADIUS Access-Request. Based on the 499 Identity included in the Access-Request, the RADIUS server may send 500 tunneling attributes within the RADIUS Access-Challenge packet. The 501 NAS can then set up the tunnel and EAP authentication may continue 502 between the client and the tunnel server. This method avoids having to 503 use attribute-specific processing or an authorize-only message. 505 However, in this case, the EAP identity is never verified by the NAS, 506 and so either the tunnel server owner must be willing to be billed for 507 all incoming calls, or other information such as the Calling-Station- 508 Id must be used to verify the user's identity for accounting purposes. 509 Where either of these conditions holds true, this scheme may be prac- 510 tically employed. 512 6.4. Authenticate at both the NAS and the tunnel network server 514 In this scheme, authentication occurs both at the NAS and the tunnel 515 network server. This requires the dial-up PPP peer to handle dual 516 authentications, with attendant LCP re-negotiations. In order to allow 517 the NAS and tunnel network server to authenticate against the same 518 database, this requires RADIUS client capability on the tunnel network 519 server, and possibly a RADIUS proxy on the NAS end. 521 Advantages of this scheme are that it allows secure authentication and 522 accounting at both ends of the tunnel; allows the use of a single 523 userID/password pair via implementation of RADIUS on the tunnel net- 524 work server; and does not require telephone-number based authentica- 525 tion, use of EAP, attribute-specific processing or addition of an 526 Authorize-Only message on the RADIUS server. This scheme allows for 527 accounting records to be generated on both the NAS and tunnel server 528 ends allowing for auditing. Also, in contrast to the previous scheme, 529 the tunnel endpoint does not need to have an account relationship with 530 the NAS owner. Thus this scheme is compatible with roaming. Disadvan- 531 tages are that unless LCP forwarding is used, LCP will need to be 532 renegotiated, and that dual authentications are required. 534 The use of dual authentication can be complex, since some clients do 535 not support it at all, and others only support only a subset of the 536 dual authentication combinations. Feasible combinations include 537 PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, 538 CHAP/EAP, EAP/CHAP, and EAP/EAP. Assuming that the required dual 539 authentication capabilities are supported, this scheme may be practi- 540 cally employed. 542 7. Telephone-number based authentication 544 7.1. Initiation sequence 546 In the case of telephone-number based authentication, a typical initi- 547 ation sequence looks like this: 549 Client and NAS: Call Connected 550 NAS to RADIUS Server: RADIUS Access-request 551 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 552 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 553 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 554 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 555 Client and Tunnel Server: PPP LCP negotiation 556 Client and Tunnel Server: PPP authentication 557 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 558 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 559 Client and Tunnel Server: NCP negotiation 560 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 561 RADIUS Server to NAS: RADIUS Accounting-Response 562 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 563 with Acct-Status-Type=Start (Optional) 564 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 566 The process begins with an incoming call to the NAS. If configured for 567 telephone-number based authentication, the NAS MUST send a RADIUS 568 Access-Request containing the Calling-Station-Id and the Called- 569 Station-Id attributes. The RADIUS server will then respond with a 570 RADIUS Access-Accept or Access-Reject. 572 The NAS MUST NOT begin PPP authentication before bringing up the tun- 573 nel. If timing permits, the NAS MAY bring up the tunnel prior to 574 beginning LCP negotiation with the client. If this is done, then LCP 575 will not need to be renegotiated between the client and tunnel server. 577 If the initial telephone-number based authentication is unsuccessful, 578 the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS 579 MUST send an LCP-Terminate and disconnect the user. 581 In the case where tunnel attributes are included in the RADIUS Access- 582 Accept, and a PPTP/L2TP tunnel is indicated, the NAS will now bring up 583 a control connection if none existed before. The control connection 584 will be of the type indicated by Tunnel-Type, over the medium indi- 585 cated by Tunnel-Medium-Type, to the tunnel server indicated by Tunnel- 586 Server-Endpoint. This is accomplished by sending a PPTP/L2TP Start- 587 Control-Connection-Request message to the tunnel server. The tunnel 588 server will then with a PPTP/L2TP Start-Control-Connection-Reply. If 589 this message indicates an error, or if the control connection is ter- 590 minated at any future time, then the NAS MUST send an LCP-Terminate 591 and disconnect the user. 593 The NAS will then proceed to send a PPTP/L2TP Incoming-Call-Request 594 message to the tunnel server. Among other things, this message will 595 contain the Call Serial Number, which along with the NAS-IP-Address 596 and Tunnel-Server-Endpoint is used to uniquely identify the call. The 597 tunnel server will reply with a PPTP/L2TP Incoming-Call-Reply message. 598 If this message indicates an error, then the NAS MUST send an LCP-Ter- 599 minate and disconnect the user. If no error is indicated, the NAS then 600 replies with a PPTP/L2TP Incoming-Call-Connected message. 602 At this point, data MAY begin to flow through the tunnel. If LCP nego- 603 tiation had been begun between the NAS and the client, the client and 604 tunnel server MAY now renegotiate LCP and begin PPP authentication; 605 otherwise, the client and tunnel server will negotiate LCP for the 606 first time, and then move on to PPP authentication. 608 If a renegotiation is required, at the time that the renegotiation 609 begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP 610 negotiation, and the client and NAS MUST NOT have begun NCP negotia- 611 tion. Rather than sending an LCP CONFACK, the NAS will instead send an 612 LCP DOWN message. The Client MAY then renegotiate LCP, and from that 613 point forward, all PPP packets originated from the client will be 614 encapsulated and sent to the tunnel server. When LCP re-negotiation 615 has been concluded, the NCP phase will begin, and the tunnel server 616 will assign an address to the client. 618 If L2TP is being used as the tunnel protocol, and LCP renegotiation is 619 required, the NAS MAY in its initial setup notification include a copy 620 of the LCP CONFACKs sent in each direction which completed LCP negoti- 621 ation. The tunnel server MAY then use this information to avoid an 622 additional LCP negotiation. With L2TP, the initial setup notification 623 can also include the authentication information required to allow the 624 tunnel server to authenticate the user and decide to accept or decline 625 the connection. However, in telephone-number based authentication, PPP 626 authentication MUST NOT occur prior to the NAS bringing up the tunnel. 627 As a result, L2TP authentication forwarding MUST NOT be employed. 629 In performing the PPP authentication, the tunnel server can access its 630 own user database, or it MAY send a RADIUS Access-Request. The latter 631 approach is useful in cases where authentication forwarding is 632 enabled, such as with roaming or shared use networks. In this case, 633 the RADIUS and tunnel servers are under the same administration and 634 are typically located close together, possibly on the same LAN. 635 Therefore having the tunnel server act as a RADIUS client provides for 636 unified user administration. Other methods are also available, such as 637 use of LDAP, described in [12], by both the tunnel and RADIUS servers. 638 Note that the tunnel server's RADIUS Access-Request is typically sent 639 directly to the local RADIUS server rather than being forwarded via 640 proxy. 642 After the tunnel has been brought up, the NAS and tunnel server MAY 643 start accounting. In the case of the NAS, this is done by sending a 644 RADIUS Accounting-Request packet with Acct-Status-Type=Start to a 645 RADIUS server. The Accounting-Request packet MUST include the follow- 646 ing attributes: Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client- 647 Endpoint, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection-Id. The 648 Accounting-Request packet MAY also include the Calling-Station-Id and 649 Called-Station-Id attributes. 651 The tunnel server can produce its own accounting records, or it MAY 652 send a RADIUS Accounting-Request packet with Acct-Status-Type=Start to 653 a local RADIUS server. In the latter case, the RADIUS Accounting- 654 Request packet MUST contain the following attributes: Tunnel-Type, 655 Tunnel-Medium-Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-End- 656 point, and Acct-Tunnel-Connection-Id. 658 The interactions involved in initiation of a compulsory tunnel with 659 telephone-number based authentication are summarized below. In order 660 to simplify the diagram that follows, we have left out the client. 661 However, it is understood that the client participates via PPP negoti- 662 ation, authentication and subsequent data interchange with the Tunnel 663 Server. 665 INITIATION SEQUENCE 667 NAS Tunnel Server RADIUS Server 668 --- ------------- ------------- 669 Call connected 670 Send RADIUS 671 Access-Request 672 with Called-Station-Id, 673 and/or Calling-Station-Id 674 LCP starts 675 IF authentication 676 succeeds 677 Send ACK with 678 Tunnel-Type, 679 Tunnel-Medium-Type, 680 Tunnel-Server-Endpoint, 681 Tunnel-Password (optional) 682 ELSE Send NAK 683 IF NAK DISCONNECT 684 ELSE 685 IF no control 686 connection exists 687 Send 688 Start-Control-Connection-Request 689 to Tunnel Server 690 Send 691 Start-Control-Connection-Reply 692 to NAS 693 ENDIF 695 Send 696 Incoming-Call-Request 697 message to Tunnel Server 698 Send Incoming-Call-Reply 699 to NAS 700 Send 701 Incoming-Call-Connected 702 message to Tunnel Server 704 Send data through the tunnel 705 Re-negotiate LCP, 706 authenticate user, 707 bring up IPCP, 708 start accounting 709 Send RADIUS 710 Accounting-Request with 711 Acct-Status-Type=Start 712 (optional) 713 Send 714 RADIUS 715 Accounting-Response 716 Send a RADIUS 717 Accounting-Request message 718 with Acct-Status-Type=Start 719 containing 720 Tunnel-Type, Tunnel-Medium-Type, 721 Acct-Tunnel-Client-Endpoint, 722 Tunnel-Server-Endpoint, 723 Acct-Tunnel-Connection-Id, 724 Calling-Station-Id, 725 Called-Station-Id. 726 Send 727 RADIUS 728 Accounting-Response 730 ENDIF 732 7.2. EAP support 734 It is expected that the Extensible Authentication Protocol (EAP) 735 described in [13] will frequently be used along with telephone number- 736 based authentication and tunneling in order to provide additional 737 security. In this case, EAP authentication may be used in the tunnel 738 authentication only, using EAP code present on the NAS, or via support 739 of EAP within RADIUS described in [11]. In this case, the initiation 740 sequence will look like this: 742 Client and NAS: Call Connected 743 Client and NAS: PPP LCP negotiation 744 NAS to RADIUS Server: RADIUS Access-Request 745 RADIUS server to NAS: RADIUS Access-Reply/Tunnel attributes 746 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 747 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 748 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 749 Client and Tunnel Server: PPP LCP re-negotiation (optional) 750 Client and Tunnel Server: EAP authentication 751 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start 752 RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message 753 Tunnel Server to Client: EAP-Request 754 Client to Tunnel Server: EAP-Response 755 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message 756 RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success 757 Client and Tunnel Server: NCP negotiation 758 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 759 RADIUS Server to NAS: RADIUS Accounting-Response 760 Tunnel Server to RADIUS Server: RADIUS Accounting-Request with 761 Acct-Status-Type=Start (Optional) 762 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 764 8. Single authentication 766 8.1. Initiation sequence 768 In the case of a single authentication compulsory tunnel, a typical 769 initiation sequence looks like this: 771 Client and NAS: Call Connected 772 Client and NAS: PPP LCP negotiation 773 Client and NAS: EAP authentication 774 NAS to RADIUS Server: RADIUS Access-request 775 RADIUS server to NAS: RADIUS Access-Challenge/Access-Reject 776 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 777 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 778 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 779 Client and Tunnel Server: PPP LCP re-negotiation (optional) 780 Client and Tunnel Server: EAP authentication 781 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 782 RADIUS server to Tunnel Server: RADIUS Access-Challenge/Access-Reject 783 Client and Tunnel Server: NCP negotiation 784 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 785 RADIUS Server to NAS: RADIUS Accounting-Response 786 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 787 with Acct-Status-Type=Start (Optional) 788 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 790 The process begins with an incoming call to the NAS, and the PPP LCP 791 negotiation between the Client and NAS. At this point, the NAS must 792 offer EAP, and the Client must accept if the negotiation is to pro- 793 ceed. If the Client is incapable of authenticating via EAP, then the 794 NAS MUST send an LCP-Terminate and disconnect the user. 796 The NAS will now typically send an EAP-Request/Identity packet to the 797 Client, and the client will respond with an EAP-Response/MyId packet. 798 The NAS now sends an Access-Request/EAP-Message/EAP-Response/MyId 799 packet to the RADIUS server, which responds with an Access-Challenge 800 or an Access-Reject. 802 If single-authentication tunneling is to be carried out, the Access- 803 Challenge packet MUST contain the Tunnel-Type, Tunnel-Medium-Type, and 804 Tunnel-Server-Endpoint Attributes; a Tunnel-Password attribute is 805 optional. The presence of tunneling attributes in the Access-Challenge 806 indicates to the NAS that a tunnel MUST be brought up prior to contin- 807 uation of the EAP conversation. As a result, if the Access-Challenge 808 contains an EAP-Message attribute, then the NAS MUST NOT send the EAP- 809 Request encapsulated in the EAP-Message prior to bringing up the tun- 810 nel. Since after the tunnel is brought up LCP will be renegotiated, 811 EAP-Message attributes are effectively ignored whenever the Access- 812 Challenge also contains tunnel attributes. 814 In the case where a PPTP/L2TP tunnel is indicated, the NAS will now 815 bring up a control connection if none existed before, and the NAS and 816 tunnel server will bring up the call. At this point, data MAY begin to 817 flow through the tunnel. The client and tunnel server MAY now renego- 818 tiate LCP and will complete PPP authentication. 820 At the time that the renegotiation begins, the NAS SHOULD NOT have 821 sent an LCP CONFACK completing LCP negotiation, and the client and NAS 822 MUST NOT have begun NCP negotiation. Rather than sending an LCP CON- 823 FACK, the NAS will instead send an LCP DOWN message. The Client MAY 824 then renegotiate LCP, and from that point forward, all PPP packets 825 originated from the client will be encapsulated and sent to the tunnel 826 server. In single authentication compulsory tunneling, L2TP authenti- 827 cation forwarding MUST NOT be employed. 829 If the tunnel server and NAS both are using the same RADIUS server, 830 the RADIUS server will respond to the tunnel server's Access-Request 831 with an Access-Challenge packet containing tunnel attributes and an 832 EAP-Message attribute, as before. On receiving the Access-Challenge 833 including tunnel attributes, the tunnel server will check whether the 834 tunnel matches the attributes returned by the RADIUS server; if so, 835 the tunnel attributes will be ignored, and the EAP-Request specified 836 in the EAP-Message attribute will be sent to the Client. If the tunnel 837 attributes do not match, then the tunnel server MUST disconnect the 838 call. 840 When LCP re-negotiation has been concluded, the NCP phase will begin, 841 and the tunnel server will assign an address to the client. 843 In performing the PPP authentication, the tunnel server can access its 844 own user database, or it MAY send a RADIUS Access-Request. After the 845 tunnel has been brought up, the NAS and tunnel server MAY start 846 accounting. 848 The interactions involved in initiation of a compulsory tunnel with 849 single authentication are summarized below. 851 INITIATION SEQUENCE 853 NAS Tunnel Server RADIUS Server 854 --- ------------- ------------- 855 Call accepted 856 LCP starts 857 EAP authentication 858 phase starts 859 Send RADIUS 860 Access-Request 861 with EAP-Message/MyId 862 attribute 863 IF MyId is known, 864 send RADIUS 865 Access-Challenge with 866 Tunnel-Type, 867 Tunnel-Medium-Type, 868 Tunnel-Server-Endpoint, 869 Tunnel-Password (optional) 870 EAP-Message (optional) 871 ELSE Send NAK 872 IF NAK DISCONNECT 873 ELSE 874 IF no control 875 connection exists 876 Send 877 Start-Control-Connection-Request 878 to Tunnel Server 879 Send 880 Start-Control-Connection-Reply 881 to NAS 882 ENDIF 884 Send 885 Incoming-Call-Request 886 message to Tunnel Server 887 Send Incoming-Call-Reply 888 to NAS 889 Send 890 Incoming-Call-Connected 891 message to Tunnel Server 893 Send data through the tunnel 894 Re-negotiate LCP, 895 authenticate user via EAP, 896 bring up IPCP, 897 start accounting 898 Send RADIUS 899 Accounting-Request with 900 Acct-Status-Type=Start 901 (optional) 902 Send 903 RADIUS 904 Accounting-Response 905 Send a RADIUS 906 Accounting-Request message 907 with Acct-Status-Type=Start 908 containing 909 Tunnel-Type, Tunnel-Medium-Type, 910 Acct-Tunnel-Client-Endpoint, 911 Tunnel-Server-Endpoint, and 912 Acct-Tunnel-Connection-Id. 913 Send 914 RADIUS 915 Accounting-Response 917 ENDIF 919 9. Dual authentication 921 9.1. Initiation sequence 923 In the case of a dual authentication, a typical initiation sequence 924 looks like this: 926 Client and NAS: PPP LCP negotiation 927 Client and NAS: PPP authentication 928 NAS to RADIUS Server: RADIUS Access-request 929 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject 930 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 931 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 932 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 933 Client and Tunnel Server: PPP LCP re-negotiation (optional) 934 Client and Tunnel Server: PPP authentication 935 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 936 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 937 Client and Tunnel Server: NCP negotiation 938 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 939 RADIUS Server to NAS: RADIUS Accounting-Response 940 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 941 with Acct-Status-Type=Start (Optional) 942 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 944 The process begins with an incoming call to the NAS. The client and 945 NAS then begin LCP negotiation. Subsequently the PPP authentication 946 phase starts, and the NAS sends a RADIUS Access-Request message to the 947 RADIUS server. If the authentication is successful, the RADIUS server 948 responds with a RADIUS Access-Accept. For users requiring mandatory 949 tunneling, the Access-Accept MUST contain the the Tunnel-Type, Tunnel- 950 Medium-Type, and Tunnel-Server-Endpoint Attributes; a Tunnel-Password 951 attribute is optional. 953 In the case where a PPTP/L2TP tunnel is indicated, the NAS will now 954 bring up a control connection if none existed before, and the NAS and 955 tunnel server will bring up the call. At this point, data MAY begin to 956 flow through the tunnel. The client and tunnel server MAY now renego- 957 tiate LCP and go through another round of PPP authentication. At the 958 time that this renegotiation begins, the NAS SHOULD NOT have sent an 959 LCP CONFACK completing LCP negotiation, and the client and NAS MUST 960 NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, 961 the NAS will instead send an LCP DOWN message. The Client MAY then 962 renegotiate LCP, and from that point forward, all PPP packets origi- 963 nated from the client will be encapsulated and sent to the tunnel 964 server. When LCP re-negotiation has been concluded, the NCP phase 965 will begin, and the tunnel server will assign an address to the 966 client. 968 If L2TP is being used as the tunnel protocol, the NAS MAY in its ini- 969 tial setup notification include a copy of the LCP CONFACKs sent in 970 each direction which completed LCP negotiation. The tunnel server MAY 971 then use this information to avoid an additional LCP negotiation. With 972 L2TP, the initial setup notification can also include the authentica- 973 tion information required to allow the tunnel server to authenticate 974 the user and decide to accept or decline the connection. However, this 975 facility creates a vulnerability to replay attacks, and can create 976 problems in the case where the NAS and tunnel server authenticate 977 against different RADIUS servers. As a result, where user-based tun- 978 neling via RADIUS is implemented, L2TP authentication forwarding 979 SHOULD NOT be employed. 981 In performing the PPP authentication, the tunnel server can access its 982 own user database, or it MAY send a RADIUS Access-Request. After the 983 tunnel has been brought up, the NAS and tunnel server MAY start 984 accounting. 986 The interactions involved in initiation of a compulsory tunnel with 987 dual authentication are summarized below. 989 INITIATION SEQUENCE 991 NAS Tunnel Server RADIUS Server 992 --- ------------- ------------- 993 Call accepted 994 LCP starts 995 PPP authentication 996 phase starts 997 Send RADIUS 998 Access-Request 999 with username and 1000 authentication data 1001 IF authentication 1002 succeeds 1003 Send ACK with 1004 Tunnel-Type, 1005 Tunnel-Medium-Type, 1006 Tunnel-Server-Endpoint, 1007 Tunnel-Password (optional) 1008 ELSE Send NAK 1009 IF NAK DISCONNECT 1010 ELSE 1011 IF no control 1012 connection exists 1013 Send 1014 Start-Control-Connection-Request 1015 to Tunnel Server 1016 Send 1017 Start-Control-Connection-Reply 1018 to NAS 1019 ENDIF 1021 Send 1022 Incoming-Call-Request 1023 message to Tunnel Server 1024 Send Incoming-Call-Reply 1025 to NAS 1026 Send 1027 Incoming-Call-Connected 1028 message to Tunnel Server 1030 Send data through the tunnel 1031 Re-negotiate LCP, 1032 authenticate user, 1033 bring up IPCP, 1034 start accounting 1035 Send RADIUS 1036 Accounting-Request with 1037 Acct-Status-Type=Start 1038 (optional) 1039 Send 1040 RADIUS 1041 Accounting-Response 1042 Send a RADIUS 1043 Accounting-Request message 1044 with Acct-Status-Type=Start 1045 containing 1046 Tunnel-Type, Tunnel-Medium-Type, 1047 Acct-Tunnel-Client-Endpoint, 1048 Tunnel-Server-Endpoint, and 1049 Acct-Tunnel-Connection-Id. 1050 Send 1051 RADIUS 1052 Accounting-Response 1054 ENDIF 1056 9.2. EAP support 1058 It is expected that the Extensible Authentication Protocol (EAP) 1059 described in [13] will frequently be used along with tunneling in 1060 order to provide additional security. EAP authentication may be used 1061 in the initial NAS authentication, in the tunnel authentication, or 1062 both, with support of EAP within RADIUS described in [11]. In the 1063 case where EAP authentication is carried out between the NAS and 1064 client, the initiation sequence will look like this: 1066 Client and NAS: PPP LCP negotiation 1067 Client and NAS: EAP Authentication 1068 NAS to RADIUS Server: RADIUS Access-Request/EAP-start 1069 RADIUS server to NAS: RADIUS Access-Challenge/EAP-Message 1070 NAS to Client: EAP-Request 1071 Client to NAS: EAP-Response 1072 NAS to RADIUS Server: RADIUS Access-Request/EAP-Message 1073 RADIUS server to NAS: RADIUS Access-Accept/EAP-Message/EAP-Success 1074 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 1075 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 1076 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 1077 Client and Tunnel Server: PPP LCP re-negotiation (optional) 1078 Client and Tunnel Server: PPP authentication 1079 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 1080 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject 1081 Client and Tunnel Server: NCP negotiation 1082 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 1083 RADIUS Server to NAS: RADIUS Accounting-Response 1084 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 1085 With Acct-Status-Type=Start(Optional) 1086 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 1088 In the case where EAP authentication is carried out between the client 1089 and tunnel server, the initiation sequence will look like this: 1091 Client and NAS: PPP LCP negotiation 1092 Client and NAS: PPP authentication 1093 NAS to RADIUS Server: RADIUS Access-request 1094 RADIUS server to NAS: RADIUS Access-Accept 1095 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 1096 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 1097 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 1098 Client and Tunnel Server: PPP LCP re-negotiation (optional) 1099 Client and Tunnel Server: EAP authentication 1100 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start 1101 RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message 1102 Tunnel Server to Client: EAP-Request 1103 Client to Tunnel Server: EAP-Response 1104 Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message 1105 RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success 1106 Client and Tunnel Server: NCP negotiation 1107 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start 1108 RADIUS Server to NAS: RADIUS Accounting-Response 1109 Tunnel Server to RADIUS Server: RADIUS Accounting-Request with 1110 Acct-Status-Type=Start (Optional) 1111 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 1113 For the negotiations described above to succeed, the client must be 1114 capable of renegotiating EAP with the tunnel server after an initial 1115 authentication with the NAS. 1117 10. Termination sequence 1119 The tear down of a compulsory tunnel involves an interaction between 1120 the client, NAS, Tunnel Server, and RADIUS Accounting server. This 1121 interaction is virtually identical regardless of whether telephone- 1122 number based authentication, single authentication, or dual authenti- 1123 cation is being used. In any of the cases, the following events occur: 1125 Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional) 1126 NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify 1127 NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Stop 1128 RADIUS Server to NAS: RADIUS Accounting-Response 1129 Tunnel Server to RADIUS Server: RADIUS Accounting-Request 1130 with Acct-Status-Type=Stop(Optional) 1131 RADIUS Server to Tunnel Server: RADIUS Accounting-Response 1133 Tunnel termination can occur due to a client request (PPP termina- 1134 tion), a tunnel server request (Call-Clear-Request), or a line problem 1135 (call disconnect). 1137 In the case of a client-requested termination, the tunnel server MUST 1138 terminate the PPP session. The tunnel server MUST subsequently send a 1139 Call-Clear-Request to the NAS. The NAS MUST then send a Call-Discon- 1140 nect-Notify message to the tunnel server, and will disconnect the 1141 call. 1143 The NAS MUST also respond with a Call-Disconnect-Notify message and 1144 disconnection if it receives a Call-Clear-Request from the tunnel 1145 server without a client-requested termination. 1147 In the case of a line problem or user hangup, the NAS MUST send a 1148 Call-Disconnect-Notify to the tunnel server. Both sides will then tear 1149 down the call. 1151 After call tear down is complete, if RADIUS accounting is being used 1152 then the NAS MUST send a RADIUS Accounting-Request with Acct-Status- 1153 Type=Stop packet to a RADIUS accounting server. The Accounting- 1154 Request packet MUST include the following attributes: Tunnel-Type, 1155 Tunnel-Medium-Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-End- 1156 point, and Acct-Tunnel-Connection-Id. 1158 The tunnel server MAY produce its own accounting records, or it MAY 1159 use RADIUS accounting. If RADIUS accounting is being used then the 1160 tunnel server MUST send a RADIUS Accounting-Request with Acct-Status- 1161 Type=Stop to a RADIUS accounting server. The Accounting-Request packet 1162 MUST contain the following attributes: Tunnel-Type, Tunnel-Medium- 1163 Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Acct- 1164 Tunnel-Connection-Id. 1166 The interactions involved in termination of a compulsory tunnel are 1167 summarized below. In order to simplify the diagram that follows, we 1168 have left out the client. However, it is understood that the client 1169 MAY participate via PPP termination and disconnection. 1171 TERMINATION SEQUENCE 1173 NAS Tunnel Server RADIUS Server 1174 --- ------------- ------------- 1175 IF user disconnected 1176 send 1177 Call-Disconnect-Notify 1178 message to tunnel server 1179 Tear down the call 1180 stop accounting 1181 Send RADIUS 1182 Accounting-Request with 1183 Acct-Status-Type=Stop 1184 (optional) 1185 Send RADIUS 1186 Accounting-Response 1187 ELSE IF client requests 1188 termination 1189 send 1190 Call-Clear-Request 1191 to the NAS 1192 Send 1193 Call-Disconnect-Notify 1194 message to tunnel server 1195 Disconnect the user 1196 Tear down the call 1197 stop accounting 1198 Send RADIUS 1199 Accounting-Request with 1200 Acct-Status-Type=Stop 1201 (optional) 1202 Send RADIUS 1203 Accounting-Response 1205 Send a RADIUS 1206 Accounting-Request message 1207 with Acct-Status-Type=Stop 1208 containing 1209 Tunnel-Type, Tunnel-Medium-Type, 1210 Acct-Tunnel-Client-Endpoint, 1211 Tunnel-Server-Endpoint, and 1212 Acct-Tunnel-Connection-Id. 1213 Send RADIUS 1214 Accounting-Response 1216 ENDIF 1218 11. Use of distinct RADIUS servers 1220 In the case that the NAS and the tunnel server are using distinct 1221 RADIUS servers, some interesting cases can arise in the provisioning 1222 of compulsory tunnels. 1224 11.1. Distinct userIDs 1226 If distinct RADIUS servers are being used, it is likely that distinct 1227 userID/password pairs will be required to complete the RADIUS and tun- 1228 nel authentications. One pair will be used in the initial PPP authen- 1229 tication with the NAS, and the second pair will be used for the tunnel 1230 authentication. 1232 However, in order to provide maximum ease of use in the case where the 1233 userID/password pairs are identical, tunnel clients typically attempt 1234 authentication with the same userID/password pair as was used in the 1235 initial PPP negotiation. Only after this fails do they prompt the user 1236 for the second pair. 1238 In this case, tunnel client implementations SHOULD take care not to 1239 put up error messages indicating a bad password. Instead a dialog 1240 SHOULD be presented requesting the tunnel userID/password combination. 1242 In the case where smart cards are being used for both authentications, 1243 the tunnel client MUST NOT attempt to present the token used in the 1244 first authentication during the second authentication, since these 1245 will never be identical. Instead the user SHOULD be prompted to enter 1246 the second token. 1248 The same issue arises in L2TP if the NAS attempts to forward authenti- 1249 cation information to the tunnel server in the initial setup notifica- 1250 tion. Since the userID/password pair used for tunnel authentication is 1251 different from that used to authenticate against the NAS, forwarding 1252 authentication information in this manner will cause the tunnel 1253 authentication to fail. As a result, where user-based tunneling via 1254 RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be 1255 employed. 1257 11.2. Multilink PPP issues 1259 It is possible for the two RADIUS servers to return different Port- 1260 Limit attributes. For example, it is conceivable that the NAS RADIUS 1261 server will only grant use of a single channel, while the tunnel 1262 RADIUS server will grant more than one channel. In this case, the cor- 1263 rect behavior is for the tunnel client to open a connection to another 1264 NAS in order to bring up a multilink bundle on the tunnel server. The 1265 client MUST NOT indicate to the NAS that this additional link is being 1266 brought up as part of a multilink bundle; this will only be indicated 1267 in the subsequent negotiation with the tunnel server. 1269 It is also conceivable that the NAS RADIUS server will allow the 1270 client to bring up multiple channels, but that the tunnel RADIUS 1271 server will allow fewer channels than the NAS RADIUS server. In this 1272 case, the client should terminate use of the excess channels. 1274 12. UserID Issues 1276 In the provisioning of roaming and shared use networks, one of the 1277 requirements is to be able to route the authentication request to the 1278 user's home RADIUS server. This authentication routing is accomplished 1279 based on the userID submitted by the user to the NAS in the initial 1280 PPP authentication. The userID is subsequently relayed by the NAS to 1281 the RADIUS server in the User-Name attribute, as part of the RADIUS 1282 Access-Request. 1284 Similarly, references [5] and [6] refer to use of the userID in deter- 1285 mining the tunnel endpoint. However, since none of these references 1286 provide guidelines for how RADIUS or tunnel routing is to be accom- 1287 plished, the possibility of conflicting interpretations exists. 1289 12.1. UserID convergence in user-based tunneling 1291 The use of RADIUS in provisioning of compulsory tunneling relieves the 1292 userID from having to do double duty. Rather than being used both for 1293 routing of the RADIUS authentication/authorization request as well for 1294 determination of the tunnel endpoint, the userID is now used solely 1295 for routing of RADIUS authentication/authorization requests. The Tun- 1296 nel-Server-Endpoint attribute returned in the RADIUS Access-Response 1297 Is then used to determine the tunnel endpoint. 1299 Since the framework described in this document allows both ISPs and 1300 tunnel users to authenticate users as well as to account for resources 1301 consumed by them, and provides for maintenance of two distinct 1302 userID/password pairs, this scheme provides a high degree of flexibil- 1303 ity. Where RADIUS proxies and tunneling are employed, it is possible 1304 to allow the user to authenticate with a single userID/password pair 1305 at both the NAS and the tunnel endpoint. This is accomplished by rout- 1306 ing the NAS RADIUS Access-Request to the same RADIUS server used by 1307 the tunnel server. 1309 As described in [8], the recommended form for the user ID is 1310 userID@realm, i.e. fred@bigco.com. 1312 13. Acknowledgements 1314 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions 1315 of this problem space, and to Allan Rubens of Ascend and Bertrand 1316 Buclin of AT&T Labs Europe for his comments on this document. 1318 14. References 1320 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 1321 Implementations." Work in progress, draft-ietf-roamops-imprev-04.txt, 1322 Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997. 1324 [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft 1325 (work in progress), draft-ietf-roamops-roamreq-05.txt, Microsoft, 1326 July, 1997. 1328 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 1329 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 1330 Daydreamer, January, 1997. 1332 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1333 1997. 1335 [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. 1336 Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." ." 1337 Internet draft (work in progress), draft-ietf-pppext-l2tp-04.txt, 1338 Ascend Communications, Microsoft, Copper Mountain Networks, U.S. 1339 Robotics, June, 1997. 1341 [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. 1342 "Point-to-Point Tunneling Protocol -- PPTP." ." Internet draft (work 1343 in progress), draft-ietf-pppext-pptp-01.txt, Ascend Communications, 1344 Microsoft, Copper Mountain Networks, U.S. Robotics, December, 1996. 1346 [7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter- 1347 net draft (work in progress), draft-ietf-radius-tunnel-auth-02.txt, 1348 Microsoft, July, 1997. 1350 [8] B. Aboba, M. A. Beadles. "The Network Access Identifier." Inter- 1351 net draft (work in progress), draft-ietf-roamops-nai-06.txt, 1352 Microsoft, CompuServe, July, 1997. 1354 [9] S. Bradner. "Key words for use in RFCs to Indicate Requirement 1355 Levels." RFC 2119, Harvard University, March, 1997. 1357 [10] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, 1358 draft-ietf-radius-ext-00.txt, Livingston, January, 1997. 1360 [11] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication 1361 Protocol Support in RADIUS." Internet draft (work in progress), draft- 1362 ietf-radius-eap-02.txt, US Robotics Access Corp., Merit Network, 1363 Microsoft, May, 1997. 1365 [12] M. Wahl, T. Howes, S. Kille. "Lightweight Directory Access Pro- 1366 tocol (v3)." ." Internet draft (work in progress), draft-ietf-asid- 1367 ldapv3-protocol-04.txt, Critical Angle Inc., Netscape, Isode Limited, 1368 March, 1997. 1370 [13] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 1371 Protocol (EAP)." ." Internet draft (work in progress), draft-ietf- 1372 pppext-eap-auth-02.txt, Merit Network, Inc., June, 1996. 1374 15. Authors' Addresses 1376 Bernard Aboba 1377 Microsoft Corporation 1378 One Microsoft Way 1379 Redmond, WA 98052 1381 Phone: 425-936-6605 1382 EMail: bernarda@microsoft.com 1384 Glen Zorn 1385 Microsoft Corporation 1386 One Microsoft Way 1387 Redmond, WA 98052 1389 Phone: 425-703-1559 1390 EMail: glennz@microsoft.com