idnits 2.17.1 draft-ietf-radius-tunnel-imp-00.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-23) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 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 17 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 287 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 456 instances of too long lines in the document, the longest one being 12 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: '... MUST This word, or the adjec...' RFC 2119 keyword, line 105: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 108: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 114: '... SHOULD NOT...' RFC 2119 keyword, line 121: '... MAY This word, or the adj...' (18 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...' == (282 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 798 looks like a reference -- Missing reference section? '4' on line 802 looks like a reference -- Missing reference section? '9' on line 819 looks like a reference -- Missing reference section? '7' on line 813 looks like a reference -- Missing reference section? '10' on line 823 looks like a reference -- Missing reference section? '5' on line 805 looks like a reference -- Missing reference section? '6' on line 809 looks like a reference -- Missing reference section? '8' on line 816 looks like a reference -- Missing reference section? '1' on line 791 looks like a reference -- Missing reference section? '2' on line 795 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 12 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 Corporation 4 Glen Zorn 5 28 February 1997 Microsoft Corporation 7 Implementation of Mandatory 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 September 1, 1997. Please 28 send comments to the authors. 30 2. Abstract 32 This document discusses implementation issues arising in the provi- 33 sioning of mandatory tunneling in dial-up networks using the PPTP and 34 L2TP protocols. This provisioning may be accomplished via the inte- 35 gration of RADIUS and tunneling protocols. 37 3. Terminology 39 Roaming "Roaming capability" may be loosely defined as the ability 40 to use any one of multiple Internet service providers 41 (ISPs), while maintaining a formal, customer-vendor rela- 42 tionship with only one. Examples of cases where roam- 43 ing capability might be required include ISP "confedera- 44 tions" and ISP-provided corporate network access support. 46 Shared Use Network 47 This is an IP dialup network whose use is shared by two or 48 more organizations. Shared use networks typically implement 49 distributed authentication and accounting in order to facil- 50 itate the relationship among the sharing parties. Since 51 these facilities are also required for implementation of 52 roaming, implementation of shared use is frequently a first 53 step toward development of roaming capabilities. In fact, 54 one of the ways by which a provider may offer roaming ser- 55 vice is to conclude shared use agreements with multiple net- 56 works. However, to date the ability to accomplish this has 57 been hampered by lack of interoperability among shared use 58 implementations. 60 Tunnel Network Server 61 This is a server which terminates a tunnel. In PPTP termi- 62 nology, this is known as the PPTP Network Server (PNS). In 63 L2TP terminology, this is known as the L2TP Network Server 64 (LNS). 66 Network Access Server 67 The Network Access Server (NAS) is the device that clients 68 dial in order to get access to the network. In PPTP termi- 69 nology this is referred to as the PPTP Access Concentrator 70 (PAC). In L2TP terminology, the NAS is referred to as the 71 L2TP Access Concentrator (LAC). 73 RADIUS server 74 This is a server which provides for authentication/autho- 75 rization via the protocol described in [3], and for account- 76 ing as described in [4]. 78 RADIUS proxy 79 In order to provide for the routing of RADIUS authentication 80 and accounting requests, a RADIUS proxy may employed. To the 81 NAS, the RADIUS proxy appears to act as a RADIUS server, and 82 to the RADIUS server, the proxy appears to act as a RADIUS 83 client. 85 Network Access Identifier 86 In order to provide for the routing of RADIUS authentication 87 and accounting requests, the userID field used in PPP and in 88 the subsequent RADIUS authentication and accounting 89 requests, known as the Network Access Identifier (NAI) may 90 contain structure. This structure provides a means by which 91 the RADIUS proxy will locate the RADIUS server that is to 92 receive the request. This same structure may also be used to 93 locate the tunnel endpoint when domain-based tunneling is 94 used. 96 4. Requirements language 98 This specification uses the same words as [9] for defining the signif- 99 icance of each particular requirement. These words are: 101 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 102 that the definition is an absolute requirement of the 103 specification. 105 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 106 nition is an absolute prohibition of the specification. 108 SHOULD This word, or the adjective "RECOMMENDED", means that there 109 may exist valid reasons in particular circumstances to 110 ignore a particular item, but the full implications must be 111 understood and carefully weighed before choosing a different 112 course. 114 SHOULD NOT 115 This phrase means that there may exist valid reasons in par- 116 ticular circumstances when the particular behavior is 117 acceptable or even useful, but the full implications should 118 be understood and the case carefully weighed before imple- 119 menting any behavior described with this label. 121 MAY This word, or the adjective "OPTIONAL", means that an item 122 is truly optional. One vendor may choose to include the 123 item because a particular marketplace requires it or because 124 the vendor feels that it enhances the product while another 125 vendor may omit the same item. An implementation which does 126 not include a particular option MUST be prepared to interop- 127 erate with another implementation which does include the 128 option, though perhaps with reduced functionality. In the 129 same vein an implementation which does include a particular 130 option MUST be prepared to interoperate with another imple- 131 mentation which does not include the option.(except, of 132 course, for the feature the option provides) 134 Silently Discard 135 The implementation discards the datagram without further 136 processing, and without indicating an error to the sender. 137 The implementation SHOULD provide the capability of logging 138 the error, including the contents of the discarded datagram, 139 and SHOULD record the event in a statistics counter. 141 An implementation is not compliant if it fails to satisfy one or more 142 of the must or must not requirements for the protocols it implements. 143 An implementation that satisfies all the must, must not, should and 144 should not requirements for its protocols is said to be "uncondition- 145 ally compliant"; one that satisfies all the must and must not require- 146 ments but not all the should or should not requirements for its proto- 147 cols is said to be "conditionally compliant." 149 5. Introduction 151 Many of the most interesting applications of tunneling protocols 152 involve dial-up network access. Some, such as the provisioning of 153 secure access to corporate intranets via the Internet, are character- 154 ized by voluntary tunneling: the tunnel is created at the request of 155 the user for a specific purpose. Other applications involve compulsory 156 tunneling: the tunnel is created automatically, without any action 157 from the user and more importantly, without allowing the user any 158 choice in the matter. 160 Examples of applications that might be implemented using compulsory 161 tunnels are Internet software upgrade servers, software registration 162 servers and banking services. These are all services which, without 163 mandatory tunneling, would probably be provided using dedicated net- 164 works or at least dedicated network access servers (NAS), since they 165 are characterized by the need to limit user access to specific hosts. 167 Given the existence of widespread support for mandatory tunneling, 168 however, these types of services could be accessed via virtually any 169 Internet service provider (ISP). The most popular means of authoriz- 170 ing dial-up network users today is through the RADIUS protocol. The 171 use of RADIUS allows the dial-up users' authorization and authentica- 172 tion data to be maintained in a central location, rather than being 173 subject to manual configuration. It makes sense to use RADIUS to cen- 174 trally administer compulsory tunneling, since RADIUS is widely 175 deployed and was designed to carry this type of information. New 176 RADIUS attributes are needed to carry the tunneling information from 177 the RADIUS server to the NAS and to transfer accounting data from the 178 NAS to the RADIUS server; those attributes are defined in [7]. 180 This document focuses on implementation issues arising in the provi- 181 sioning of mandatory tunneling in dialup networks. The use of RADIUS 182 in provisioning of mandatory tunneling has several advantages. These 183 include: 185 User-based tunneling 186 Auditing capabilities 187 Telephone-number based authentication and accounting 189 5.1. User-based Tunneling 191 Current proposals for routing of tunnel requests include static tun- 192 neling, where all users are automatically tunneled to a given end- 193 point, and realm-based tunneling, where the tunnel endpoint is deter- 194 mined from the realm portion of the userID. User-based tunneling as 195 provided by integration of RADIUS and tunnel protocols offers signifi- 196 cant advantages over both of these approaches. 198 Static tunneling requires dedication of a NAS device to the purpose. 199 In the case of an ISP, this is undesirable because it requires them to 200 dedicate a NAS to tunneling service for a given corporate customer, 201 rather than allowing them to use existing NASes deployed in the field. 202 As a result static tunneling is likely to be costly for deployment of 203 a global service. 205 Realm-based tunneling assumes that all users within a given realm wish 206 to be treated the same way. This limits a corporation's flexibility in 207 managing the account rights of their users. For example, BIGCO may 208 wish to provide Janet with an account that allows access to both the 209 Internet and the intranet, with Janet's intranet access provided by a 210 tunnel server located in the engineering department. However BIGCO may 211 wish to provide Fred with an account that provides only access to the 212 intranet, with Fred's intranet access provided by a tunnel network 213 server located in the sales department. Such a situation cannot be 214 accommodated with realm-based tunneling. 216 On the other hand, user-based tunneling as enabled by the attributes 217 defined in [7] provides BIGCO with the flexibility to administer tun- 218 neling behavior on a per-user basis. When deployed in concert with 219 roaming, user-based tunneling offers corporations the ability to pro- 220 vide their users with access to the corporate Intranet on a global 221 basis. 223 As described in [7], provisioning of mandatory tunneling requires no 224 new RADIUS messages, and implementation of three new RADIUS 225 attributes. During authentication, the new attributes allow the RADIUS 226 server to indicate the tunnel protocol (PPTP, L2F, L2TP, etc.), the 227 tunnel medium (X.25, ATM, Frame Relay, IP) and the address of the 228 remote tunnel endpoint. During accounting, the new attributes allow 229 the NAS to provide the RADIUS server with these same attributes, as 230 well as the tunnel client address and Connection Identifier. Together 231 the Connection Identifier and tunnel client and endpoint addresses 232 uniquely identify the call, linking together the NAS and tunnel server 233 accounting records for a given call. 235 5.2. Auditing Capabilities 237 The integration of RADIUS and tunnel protocols allows the ISP and the 238 corporation to synchronize their accounting activities so that each 239 side receives a record of the user's resource consumption. This pro- 240 vides the corporation with the means to audit ISP bills. This capabil- 241 ity is particularly important when the user is taking advantage of 242 roaming capabilities in order to connect to the corporate intranet 243 from a remote location. 245 As described in [7], auditing requires implementation of number of new 246 RADIUS attributes. These new attributes allow the RADIUS server to 247 provide information within the Accounting-Request packet that will 248 allow matching with the corresponding tunnel server Accounting-Request 249 packet. This information includes the Connection-Identifier, the tun- 250 nel protocol (PPTP, L2F, or L2TP), tunnel-media (X.25, ATM, Frame 251 Relay, IP) the address of the remote tunnel endpoint, and the tunnel 252 client address. 254 5.2.1. Connection-Identifier 256 In L2TP the Call-Serial-Number is used as the RADIUS Connection Iden- 257 tifier, and the tuple (userID, tunnel-client-endpoint address, tunnel- 258 server-endpoint address, Call-Serial-Number) is used to uniquely iden- 259 tify the call. In order to protect against wrapping due to reboots or 260 call volume, it is recommended that a 64-bit NTP timestamp be used as 261 the Call-Serial Number. 263 While the PPTP specification states that the Call-Serial-Number SHOULD 264 be unique, it does not mandate this. In addition, no method for deter- 265 mining the Call-Serial-Number is specified, which leaves open the pos- 266 sibility of wrapping after a reboot. Finally since the Call-Serial- 267 Number is a 16-bit value, the Call-Serial-Number is not sufficient to 268 distinguish a given call from all other calls over an extended time 269 period. For example, let us assume that the Call Serial Number is 270 assigned monotonically, and that the NAS in question has 96 ports. If 271 the NAS ports are kept continually busy and the average call is of 20 272 minutes duration, then the Call Serial Number will wrap within 273 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days. 275 In order to rectify this, it is recommended that another message be 276 added to PPTP so that the NAS could provide the tunnel server with a 277 unique Connection Identifier. It is recommended that a 64-bit NTP 278 timestamp be used for this purpose. This is not an issue in L2TP since 279 the Call-Serial-Number string may be of variable length. 281 5.3. Telephone-number based authentication and accounting 283 Using the Calling-Station-ID and Called-Station-ID RADIUS attributes, 284 authorization and subsequent tunnel attributes can be based on the 285 phone number originating the call, or the number being called. This 286 allows the RADIUS server to authorize users based on the calling phone 287 number (with or without a userID/password combination), or to select 288 the tunnel type, tunnel medium, or tunnel endpoint address based on 289 the calling or called phone number. Similarly, the tunnel server may 290 choose to reject or accept the call based on the Dialed Number and 291 Dialing Number included in the Incoming-Call-Request packet sent by 292 the NAS. 294 The use of RADIUS accounting by the NAS and/or the tunnel server 295 allows for accounting to take place based on the Calling-Station-ID 296 and/or Called-Station-ID. 298 6. Alternatives for implementation of mandatory tunneling 300 There are several alternatives for integration of RADIUS and tunnel- 301 ing: 303 Authenticate at the NAS 304 Authenticate at the NAS, and forward the RADIUS reply 305 Authenticate at the tunnel network server 306 Authenticate at both the NAS and the tunnel network server 308 We discuss each of these alternatives in turn. 310 6.1. Authenticate at the NAS 312 With this approach, authentication and authorization (including tun- 313 neling information) occurs once, at the NAS. The advantages of this 314 approach are that it disallows network access for unauthorized NAS 315 users; and allows RADIUS accounting to be used at the NAS. Disadvan- 316 tages are that it requires that the tunnel network server trust the 317 NAS, since no user authentication occurs on the tunnel network server 318 end of the tunnel. Another disadvantage is that this does not allow 319 LCP parameters to be re-negotiated by the tunnel network server. Also, 320 due to the lack of user authentication, accounting cannot take place 321 at the tunnel network server with strong assurance that the correct 322 party is being billed. 324 6.2. Authenticate at the NAS, and forward the RADIUS reply 326 With this approach, authentication and authorization occurs once, at 327 the NAS end of the tunnel and the RADIUS reply is forwarded to the 328 tunnel network server. This approach disallows network access for 329 unauthorized NAS users; does not require trust between the NAS and 330 tunnel network server ends of the tunnel; and allows for RADIUS 331 accounting to be used at both ends of the tunnel. However, it also 332 requires that both ends share the same secret with the RADIUS server, 333 since that's the only way that the tunnel network server could check 334 the RADIUS reply. Also, the tunnel network server must share secrets 335 with all the NASes and associated RADIUS servers. Other disadvantages 336 include lack of provision for LCP renegotiation by the tunnel network 337 server; and the tunnel network server must know how to handle and ver- 338 ify RADIUS Access-Accept messages. 340 While this scheme may be workable if the reply comes directly from a 341 RADIUS server, it would become unmanageable if a RADIUS proxy is 342 involved, since the reply would be authenticated using the secret 343 shared by the client and proxy, rather than the RADIUS server. 345 6.3. Authenticate at the tunnel network server 347 In this scheme, authentication and authorization occurs once at the 348 tunnel network server. This requires that the NAS determine that the 349 user needs to be tunneled (through a RADIUS request, manual configura- 350 tion, etc.). Since the RADIUS specification [3] requires that either a 351 CHAP or PAP password be present in an Access-Request message, but 352 doesn't require that it be non-empty, this scheme probably requires 353 either attribute-specific processing on the RADIUS server, or addition 354 of a new "Authorize-Only" RADIUS message. 356 In attribute-specific processing an attribute is used to signal tunnel 357 initiation. For example, tunnel attributes can be sent back if the PAP 358 password is empty (or "tunnel" or "L2TP"). Alternatively, a user 359 could prefix his NAI with some special character ('*') if he wanted to 360 be tunneled. This particular solution does not support compulsory tun- 361 neling. Another solution involves keying on the domain portion of the 362 NAI; all users in domain 'X' would be tunneled to address 'Y'. This 363 proposal supports compulsory tunneling, but does not provide for user- 364 based tunneling. 366 An Authorize-Only message would not include a CHAP or PAP password; 367 nevertheless, in response the RADIUS server would return the attribute 368 list. In order to prevent password guessing attacks, an Authorize-Only 369 message would need to be authenticated via the RADIUS shared secret. 370 This could be accomplished via the Signature attribute described in 371 [10]. 373 Note that when either attribute-specific processing or authorization- 374 only messages are used, the tunnel network server would need to rene- 375 gotiate LCP. Note also that in order for the NAS to start accounting 376 on the connection, it would need to use the identity claimed by the 377 user in authenticating to the tunnel network server, since it did not 378 verify the identity via RADIUS. However, in order for that to be of 379 any use in accounting, the tunnel endpoint needs to have an account 380 relationship with the NAS owner. Thus even if a user has an account 381 with the NAS owner, they cannot use this account for tunneling unless 382 the tunnel endpoint also has a business relationship with the NAS 383 owner. Without putting in place a public key infrastructure, it is not 384 clear how the NAS would be able to verify the existence of such a 385 business relationship in a scalable manner. Thus this approach nulli- 386 fies many of the benefits of roaming. 388 6.4. Authenticate at both the NAS and the tunnel network server 390 In this scheme, authentication occurs both at the NAS and the tunnel 391 network server. This requires the dial-up PPP peer to handle dual 392 authentications, with attendant LCP re-negotiations. In order to allow 393 the NAS and tunnel network server to authenticate against the same 394 database, this requires RADIUS client capability on the tunnel network 395 server, and possibly a RADIUS proxy on the NAS end. 397 Advantages of this scheme are that it allows secure authentication and 398 accounting at both ends of the tunnel; allows the use of a single 399 userID/password pair via implementation of RADIUS on the tunnel net- 400 work server; and does not require attribute-specific processing or 401 addition of an Authorize-Only message on the RADIUS server. This 402 scheme allows for accounting records to be generated on both the NAS 403 and tunnel server ends allowing for auditing. Also, in contrast to the 404 previous scheme, the tunnel endpoint does not need to have an account 405 relationship with the NAS owner. Thus this scheme is compatible with 406 roaming. Disadvantages are that LCP must be renegotiated, and that 407 dual authentications are required. 409 Considering all the advantages and disadvantages of the various 410 schemes, we believe that this scheme is the best choice, and as a 411 result, the rest of this document focuses on the dual authentication 412 scheme. 414 7. Initiation Sequence 416 The provisioning of a mandatory tunnel involves an interaction between 417 the client, NAS, Tunnel Server, and RADIUS server. The following 418 events occur in initiation of the connection: 420 Client and NAS: PPP LCP negotiation 421 Client and NAS: PPP authentication 422 NAS to RADIUS Server: RADIUS Access-request 423 RADIUS server to NAS: RADIUS Access-reply/Access-Reject 424 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request 425 Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply 426 NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected 427 Client and Tunnel Server: PPP LCP re-negotiation 428 Client and Tunnel Server: PPP re-authentication 429 Tunnel Server to RADIUS Server: RADIUS Access-request (optional) 430 RADIUS server to Tunnel Server: RADIUS Access-reply/Access-Reject 431 Client and Tunnel Server: IPCP negotiation 432 NAS to RADIUS Server: RADIUS Accounting-Request/START 433 RADIUS Server to NAS: RADIUS Accounting-Reply 434 Tunnel Server to RADIUS Server: RADIUS Accounting-Request/START (Optional) 435 RADIUS Server to Tunnel Server: RADIUS Accounting-Reply 437 The process begins with an incoming call to the NAS. The client and 438 NAS then begin LCP negotiation. Subsequently the PPP authentication 439 phase starts, and the NAS sends a RADIUS Access-Request message to the 440 RADIUS server. If the authentication is successful, the RADIUS server 441 responds with a RADIUS Access-Accept including the Tunnel-Type (L2F, 442 PPTP, L2TP), Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP), and Tun- 443 nel-Server-Endpoint attributes. 445 It is possible that RADIUS proxies may be used to forward the Access- 446 Reply message from the RADIUS server to the NAS. In order to ensure 447 that the mandatory tunnel attributes arrive without modification, 448 RADIUS proxies present in the path MUST NOT modify these attributes. 450 Since this is a mandatory tunnel, address assignment will be handled 451 by the tunnel server rather than the NAS. As a result, if tunnel 452 attributes are present, the NAS MUST ignore any address assignment 453 attributes sent by the RADIUS server. In addition, the NAS and client 454 MUST NOT begin IPCP negotiation, since this could create a time window 455 in which the client will be capable of sending packets to the Inter- 456 net, which is not permitted under mandatory tunneling. If the authen- 457 tication is unsuccessful, the RADIUS server sends a RADIUS Access- 458 Reject. In this case, the NAS MUST disconnect the user. 460 The NAS will now bring up a control connection to the tunnel server if 461 none existed before. This is accomplished by sending a PPTP/L2TP 462 Start-Control-Connection-Request message to the tunnel server. The 463 tunnel server replies with a PPTP/L2TP Start-Control-Connection-Reply. 464 If this message indicates an error, or if the control connection is 465 terminated at any future time, then the NAS MUST disconnect the user. 467 The NAS will then proceed to send a PPTP/L2TP Incoming-Call-Request 468 message to the tunnel server. Among other things, this message will 469 contain the Call Serial Number, which along with the IP addresses of 470 the NAS and tunnel server, is used to uniquely identify the call. The 471 tunnel server will reply with a PPTP/L2TP Incoming-Call-Reply message. 472 If this message indicates an error, then the NAS MUST disconnect the 473 user. The NAS then replies with an Incoming-Call-Connected message. 475 At this point, data may begin to flow through the tunnel. The client 476 and tunnel server must now renegotiate LCP and go through another 477 round of PPP authentication. At the time that this renegotiation 478 begins, the NAS should not have sent the final packet confirming the 479 success of the initial authentication, and the client and NAS MUST NOT 480 have begun IPCP negotiation. Rather than sending the final confirma- 481 tion packet, the NAS will instead send an LCP down message. The Client 482 will then attempt to renegotiate LCP, and from that point forward, all 483 PPP packets originated from the client will be encapsulated and sent 484 to the tunnel server. When LCP negotiation has been concluded, the 485 IPCP phase will begin, and the tunnel server will assign an IP address 486 to the client. 488 If L2TP is being used as the tunnel protocol, an alternative method 489 may be used. This requires the NAS in its initial setup notification 490 to include a copy of the LCP CONFACKs sent in each direction which 491 completed LCP negotiation. The tunnel server may then use this infor- 492 mation to avoid an additional LCP negotiation. With L2TP, the initial 493 setup notification may also include the authentication information 494 required to allow the tunnel server to authenticate the user and 495 decide to accept or decline the connection. However, this facility 496 should be used with caution since it creates a vulnerability to replay 497 attacks, and in addition may create problems in the case where the NAS 498 and tunnel server authenticate against different RADIUS servers. 500 In performing the PPP authentication, the tunnel server may access its 501 own user database, or it may send a RADIUS Access-Request. The latter 502 approach is useful in cases where authentication forwarding is 503 enabled, such as with roaming or shared use networks. In this case, 504 the RADIUS and tunnel servers are under the same administration and 505 are typically located close together, possibly on the same LAN. There- 506 fore having the tunnel server act as a RADIUS client provides for uni- 507 fied user administration. Other methods are also available, such as 508 use of LDAP by both the tunnel and RADIUS servers. Note that the tun- 509 nel server's RADIUS Access-Request is typically sent directly to the 510 local RADIUS server rather than being forwarded via proxy. 512 After the tunnel has been brought up, the NAS and tunnel server may 513 start accounting. In the case of the NAS, this is done by sending a 514 RADIUS Accounting-Request/START packet to the RADIUS server. The 515 Accounting-Request packet MUST include the following attributes: Tun- 516 nel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server- 517 Endpoint, and Connection-Identifier. 519 The tunnel server may produce its own accounting records, or it may 520 send a RADIUS Accounting-Request/START packet to a local RADIUS 521 server. In the latter case, the RADIUS Accounting-Request/START packet 522 MUST contain the following attributes: Tunnel-Type, Tunnel-Medium- 523 Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection- 524 Identifier. 526 The interactions involved in initiation of a mandatory tunnel are sum- 527 marized below. In order to simplify the diagram that follows, we have 528 left out the client. However, it should be understood that the client 529 participates via PPP negotiation, authentication and subsequent data 530 interchange with the Tunnel Server. 532 INITIATION SEQUENCE 534 NAS Tunnel Server RADIUS Server 535 --- ------------- ------------- 536 Call accepted 537 LCP starts 538 PPP authentication 539 phase starts 540 Send RADIUS 541 Access-Request 542 with username and 543 authentication data 544 IF authentication 545 succeeds 546 Send ACK with 547 Tunnel-Type, 548 Tunnel-Medium-Type, 549 Tunnel-Server-Endpoint 550 ELSE Send NAK 551 IF NAK DISCONNECT 552 ELSE 553 IF no control 554 connection exists 555 Send 556 Start-Control-Connection-Request 557 to Tunnel Server 558 Send 559 Start-Control-Connection-Reply 560 to NAS 561 ENDIF 563 Send 564 Incoming-Call-Request 565 message to Tunnel Server 566 Send Incoming-Call-Reply 567 to NAS 568 Send 569 Incoming-Call-Connected 570 message to Tunnel Server 572 Send data through the tunnel 573 Re-negotiate LCP, 574 authenticate user, 575 bring up IPCP, 576 start accounting 577 Send RADIUS 578 Accounting-Request 579 (optional) 580 Send 581 RADIUS 582 Accounting-Reply 583 Send a RADIUS 584 Accounting-Request message 585 with Acct-Status-Type 586 set to Start, containing 587 Tunnel-Type, Tunnel-Medium-Type, 588 Tunnel-Client-Endpoint, 589 Tunnel-Server-Endpoint, and 590 Connection-Identifier. 591 Send 592 RADIUS 593 Accounting-Reply 595 ENDIF 597 8. Termination Sequence 599 As with initiation, the tear down of a mandatory tunnel involves an 600 interaction between the client, NAS, Tunnel Server, and RADIUS server. 601 The following events occur in termination of the connection: 603 Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional) 604 NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify 605 NAS to RADIUS Server: RADIUS Accounting-Request/STOP 606 RADIUS Server to NAS: RADIUS Accounting-Reply 607 Tunnel Server to RADIUS Server: RADIUS Accounting-Request/STOP (Optional) 608 RADIUS Server to Tunnel Server: RADIUS Accounting-Reply 610 Tunnel termination may occur due to a client request (PPP termina- 611 tion), a tunnel server request (Call-Clear-Request), or a telco issue 612 (call disconnect). 614 In the case of a client-requested termination, the tunnel server will 615 terminate the PPP session. The tunnel server will subsequently send a 616 Call-Clear-Request to the NAS. The NAS will then send a Call-Discon- 617 nect-Notify message to the tunnel server, and will disconnect the 618 call. 620 The NAS will also respond with a Call-Disconnect-Notify message and 621 disconnection if it receives a Call-Clear-Request from the tunnel 622 server without a client-requested termination. 624 In the case of a telco issue or user hangup, the NAS will send a Call- 625 Disconnect-Notify to the tunnel server. Both sides will then tear down 626 the call. 628 After call tear down is complete, the NAS and tunnel server may stop 629 accounting. In the case of the NAS, this is done by sending a RADIUS 630 Accounting-Request/STOP packet to the RADIUS server. The Accounting- 631 Request packet MUST include the following attributes: Tunnel-Type, 632 Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, 633 and Connection-Identifier. 635 The tunnel server may produce its own accounting records, or it may 636 send a RADIUS Accounting-Request/STOP packet to a local RADIUS server. 637 In the latter case, the RADIUS Accounting-Request/STOP packet MUST 638 contain the following attributes: Tunnel-Type, Tunnel-Medium-Type, 639 Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection-Identi- 640 fier. 642 The interactions involved in termination of a mandatory tunnel are 643 summarized below. In order to simplify the diagram that follows, we 644 have left out the client. However, it should be understood that the 645 client participates via PPP termination and disconnection. 647 TERMINATION SEQUENCE 649 NAS Tunnel Server RADIUS Server 650 --- ------------- ------------- 651 IF user disconnected 652 send 653 Call-Disconnect-Notify 654 message to tunnel server 655 Tear down the call 656 stop accounting 657 Send RADIUS 658 Accounting-Request/STOP 659 message (optional) 660 Send RADIUS 661 Accounting-Reply 662 ELSE IF client requests 663 termination 664 send 665 Call-Clear-Request 666 to the NAS 667 Send 668 Call-Disconnect-Notify 669 message to tunnel server 670 Disconnect the user 671 Tear down the call 672 stop accounting 673 Send RADIUS 674 Accounting-Request/STOP 675 message (optional) 676 Send RADIUS 677 Accounting-Reply 679 Send a RADIUS 680 Accounting-Request message 681 with Acct-Status-Type 682 set to Stop, containing 683 Tunnel-Type, Tunnel-Medium-Type, 684 Tunnel-Client-Endpoint, 685 Tunnel-Server-Endpoint, and 686 Connection-Identifier. 687 Send RADIUS 688 Accounting-Reply 690 ENDIF 692 9. Use of distinct RADIUS servers 694 In the case that the NAS and the tunnel server are using distinct 695 RADIUS servers, some interesting cases can arise in the provisioning 696 of mandatory tunnels. 698 9.1. Distinct userIDs 700 If distinct RADIUS servers are being used, it is likely that two dis- 701 tinct userID/password pairs will be required to complete the RADIUS 702 and tunnel authentications. One pair will be used in the initial PPP 703 authentication, and the second pair will be used for the tunnel 704 authentication. 706 However, in order to provide maximum ease of use in the case where the 707 userID/password pairs are identical, tunnel clients typically attempt 708 authentication with the same userID/password pair as was used in the 709 initial PPP negotiation. Only after this fails do they prompt the user 710 for the second pair. 712 In this case, tunnel client implementations should take care not to 713 put up error messages indicating a bad password. Instead a dialog 714 should be presented requesting the tunnel userID/password combination. 716 In the case where token cards are being used for both authentications, 717 the tunnel client MUST NOT attempt to present the token used in the 718 first authentication during the second authentication, since these 719 will never be identical. Instead the user should be prompted to enter 720 the second token. 722 The same issue arises in L2TP if the NAS attempts to forward authenti- 723 cation information to the tunnel server in the initial setup notifica- 724 tion. Since the userID/password pair used for tunnel authentication is 725 different from that used to authenticate against the NAS, forwarding 726 authentication information in this manner will cause the tunnel 727 authentication to fail. As a result, where user-based tunneling via 728 RADIUS is implemented, L2TP authentication forwarding should not be 729 employed. 731 9.2. Multilink PPP issues 733 It is possible for the two RADIUS servers to return distinct MAX CHAN- 734 NEL attributes. For example, it is conceivable that the NAS RADIUS 735 server will only grant use of a single channel to the user, while the 736 tunnel RADIUS server will grant more than one channel. In this case, 737 the correct behavior is for the tunnel client to open a connection to 738 another NAS in order to bring up a multilink bundle on the tunnel 739 server. The client MUST NOT indicate to the NAS that this additional 740 link is being brought up as part of a multilink bundle; this will only 741 be indicated in the subsequent negotiation with the tunnel server. 743 It is also conceivable that the NAS RADIUS server will allow the 744 client to bring up dual channels, but that the tunnel RADIUS server 745 will only allow a single channel. In this case, the client should ter- 746 minate use of the second channel. 748 10. UserID Issues 750 In the provisioning of roaming and shared use networks, one of the 751 requirements is to be able to route the authentication request to the 752 user's home RADIUS server. This authentication routing is accomplished 753 based on the userID submitted by the user to the NAS in the initial 754 PPP authentication. 756 Similarly, references [5] and [6] refer to use of the userID in deter- 757 mining the tunnel endpoint. However, since none of these references 758 provide guidelines for how RADIUS or tunnel routing is to be accom- 759 plished, the possibility of conflicting interpretations exists. 761 10.1. UserID convergence in user-based tunneling 763 The use of RADIUS in provisioning of mandatory tunneling relieves the 764 userID from having to do double duty. Rather than being used both for 765 routing of the RADIUS authentication/authorization request as well for 766 determination of the tunnel endpoint, the userID is now used solely 767 for routing of RADIUS authentication/authorization requests. The 768 response to that request is in turn used to determine the tunnel end- 769 point. 771 Since the framework described in this document allows both ISPs and 772 tunnel users to authenticate users as well as account for resources 773 consumed by them, and provides for maintenance of two distinct 774 userID/password pairs, it is believed that this scheme offers the max- 775 imum degree of flexibility. Where RADIUS proxies and tunneling are 776 employed, it is possible to allow the user to authenticate with a sin- 777 gle userID/password pair at both the NAS and the tunnel endpoint. This 778 is accomplished by routing the NAS RADIUS Access-Request to the same 779 RADIUS server used by the tunnel server. 781 As described in [8], the recommended form for the user ID is 782 userID@domain, i.e. fred@bigco.com. 784 11. Acknowledgements 786 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions 787 of this problem space. 789 12. References 791 [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- 792 tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass 793 Alliance, Asiainfo, January, 1997. 795 [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf- 796 roamops-roamreq-02.txt, Microsoft, January, 1997. 798 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 799 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 800 Daydreamer, January, 1997. 802 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 803 1997. 805 [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. 806 Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft- 807 ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996. 809 [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, J. Taarud, W. A. 810 Little. "Point-to-Point Tunneling Protocol -- PPTP." draft-ietf- 811 pppext-pptp-00.txt, Ascend Communications, June, 1996. 813 [7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft- 814 ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996. 816 [8] B. Aboba. "The Network Access Identifier." draft-ietf-roamops- 817 nai-01.txt, Microsoft Corporation, February, 1997. 819 [9] S. Bradner. "Key words for use in RFCs to Indicate Requirement 820 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 821 1996. 823 [10] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- 824 ext-00.txt, Livingston, January, 1997. 826 13. Authors' Addresses 828 Bernard Aboba 829 Microsoft Corporation 830 One Microsoft Way 831 Redmond, WA 98052 833 Phone: 206-936-6605 834 EMail: bernarda@microsoft.com 835 Glen Zorn 836 Microsoft Corporation 837 One Microsoft Way 838 Redmond, WA 98052 840 Phone: 206-703-1559 841 EMail: glennz@microsoft.com