idnits 2.17.1 draft-ietf-pppext-l2tp-sec-04.txt: 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-26) 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 page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 68: '...n states that the IPSEC protocols MUST...' RFC 2119 keyword, line 96: '... o MUST, SHALL, or MANDATORY ...' RFC 2119 keyword, line 99: '... o SHOULD or RECOMMEND -- Thi...' RFC 2119 keyword, line 102: '... o MAY or OPTIONAL -- This it...' RFC 2119 keyword, line 143: '... The 'K' bit MUST be set to one (1) ...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1750 (ref. '5') (Obsoleted by RFC 4086) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Pat R. Calhoun 3 INTERNET DRAFT Sun Microsystems, Inc. 4 Category: Informational W. Mark Townsley 5 Title: draft-ietf-pppext-l2tp-sec-04.txt Cisco Systems 6 Date: July 1998 Sumit A. Vakil 7 VPNet Technologies, Inc. 8 Don Grosser 9 IBM Corporation 11 Layer Two Tunneling Protocol "L2TP" 12 Security Extensions for Non-IP networks 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or 31 munnari.oz.au. 33 Abstract 35 The L2TP document [1] defines the base protocol which describes the 36 method of tunneling PPP [2] data. The L2TP document states that the 37 security mechanism used over an IP network is to use the IETF's IPSEC 38 protocols. 40 L2TP was designed in such a way as to be able to run over any 41 underlying layer (i.e. Frame Relay, ATM, etc.). This document 42 specifies extensions to the L2TP protocol in order to provide 43 authentication and integrity of individual packets in a tunneled 44 session over a network where IPSEC or another suitable security 45 protocol is not available. 47 Table of Contents 49 1.0 Introduction 50 1.1 Conventions 51 2.0 L2TP Security Header Format 52 3.0 Protection Against Attacks 53 3.1 Denial of Service Attacks 54 3.2 Replay Attacks 55 3.3 Compromise of the Master Key 56 4.0 AVP Hiding 57 5.0 Security Association Negotiation 58 5.1 Renegotiate-Security-Association Message 59 5.2 Encoded Message Key 60 5.3 Message Security Parameter Index 61 6.0 Acknowledgments 62 7.0 References 63 8.0 Authors' Addresses 64 Appendix A: Additional Recommendations for secure L2TP implementations 66 1.0 Introduction 68 The L2TP protocol specification states that the IPSEC protocols MUST 69 be used over an IP network for L2TP to operate in a secure manner. 70 However, L2TP may be run on a link layer that does not have a 71 security mechanism such as IPSEC available. In this case it becomes 72 necessary for L2TP to provide its own mechanism for packet level 73 security. 75 This document will describe how authentication and integrity of L2TP 76 packets will be handled over networks where IPSEC or another suitable 77 security protocol does not exist. It does not intend to provide a 78 mechanism for encryption of packets. If data encryption is necessary, 79 then the user may utilize ECP or another form of end to end 80 encryption. 82 The security extensions defined here also provide the added 83 flexibility to negotiate security separately over the control and 84 data channels. This may be desirable in some situations, particularly 85 where processing power may be at a minimum, but some level of 86 security is still desired. 88 By design, several of the constructs used here draw upon those being 89 developed in the IPSEC working group. 91 1.1 Conventions 93 The following language conventions are used in the items of specifi- 94 cation in this document: 96 o MUST, SHALL, or MANDATORY -- This item is an absolute 97 requirement of the specification. 99 o SHOULD or RECOMMEND -- This item should generally be followed 100 for all but exceptional circumstances. 102 o MAY or OPTIONAL -- This item is truly optional and may be 103 followed or ignored according to the needs of the 104 implementor. 106 2.0 L2TP Security Header Format 108 The L2TP Header has been modified as follows in order to accommodate 109 the new security extension. 111 0 1 2 3 112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |T|1|1|1|1|K|0|0| | Ver | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Tunnel ID | Call ID | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Ns | Nr | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Initialization Vector | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Initialization Vector | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Initialization Vector | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Initialization Vector | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Security Parameters Index | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Message Integrity Check | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Message Integrity Check | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Message Integrity Check | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Message Type AVP... | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | ... (8 bytes) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 K Bit 143 The 'K' bit MUST be set to one (1) when the security extension is 144 present. The behavior of the 'K' bit is identical on both the control 145 and data channel. 147 Initialization Vector (IV) 149 This field MUST contain a cryptographically random 128 bit value [5]. 151 Security Parameters Index (SPI) 153 The SPI is an arbitrary four octet value. It is an unstructured 154 opaque index which is used in conjunction with the Tunnel ID to 155 identify a particular Security Association. The behavior of the SPI 156 is identical on the control and data channel. 158 The value inserted in this field is the locally generated SPI value 159 which references the key used in generating the Message Integrity 160 Check. 162 Message Integrity Check (MIC) 164 The MIC contains the result of the HMAC-MD5-96 algorithm [3][4] as 165 applied over the entire L2TP packet. The behavior of the MIC is 166 identical on the control and data channel. 168 3.0 Protection Against Attacks 170 This section will define certain methods of protecting against 171 specific known types of attacks. 173 3.1 Denial of Service Attacks 175 There currently exists a Denial of Service Attack whereby a malicious 176 host can issue a stream of Start-Control-Connection- Request messages 177 to an L2TP host on a network. 179 Although an implementation MUST time-out when a Start-Control- 180 Connection-Connected has not been received within a given window, 181 there is still a possibility that if the messages were received fast 182 enough the L2TP host would deplete its Control Connection Control 183 Blocks. This form of attack is aggravated when the malicious host 184 sends the packets with a random source IP address. 186 One form of protection against this attack is to have a local list of 187 trusted hosts, however this does not scale very well when providing a 188 roaming service from anywhere on the Internet. Furthermore, 189 enforcing a security policy based on a source address is a very weak 190 form of protection. 192 Another method of protecting against this form of attack is to have 193 the 'K' bit set in the initial Start-Control-Connection-Request 194 message. The message would be signed with the common secret (or key, 195 see below for more details). This scheme will ensure that only 196 authenticated Start-Control-Connection-Requests will be accepted, 197 making this type of attack very inconvenient for a malicious user to 198 create. 200 In order for this scheme to be successful, it is imperative that the 201 base specification require that a base implementation which does not 202 support any extensions MUST reject a Start-Control-Connection-Request 203 message with a 'K' bit set. 205 3.2 Replay Attacks 207 One common attack is the replay attack. This requires that a 208 malicious user gain access to the network where packets are routed. 210 There are two different types of replay attacks in the current L2TP 211 protocol. The first takes advantage of the fact that since a secret 212 is a long lived key (known as the master key), a malicious user can 213 retrieve the Stop-Control-Connection-Request message from two L2TP 214 peers and replay it at a later date when an L2TP tunnel is active 215 between both peers. 217 This form of attack is further complicated by the fact that the 218 malicious user must inject the packet when the sequence number in the 219 replayed packet is within the window of the receiver. This can be 220 achieved using a brute force type attack by constantly sending the 221 packet until the L2TP host accepts it. One more complication for the 222 malicious user is the fact that the Tunnel and Call identifiers MUST 223 be the same in the new session being attacked. This is possible, but 224 improbable if the Tunnel and Call IDs are selected in a sufficiently 225 random manner (while L2TP does not specify a method for selecting 226 Tunnel and Call IDs, we reccommend choosing a method that is as 227 unpredictable as possible to help guard against replay attacks, 228 regardless if a security protocol is being utilized over the link). 230 The second type of attack occurs when a user attempts to replay data 231 packets being tunneled. An example of a malicious packet to replay 232 would be a LCP Terminate Request message from a previous session. In 233 this case, again, the Tunnel and the Call IDs MUST be identical for 234 the L2TP peer to accept the packet. 236 However, if a malicious user was to simply snoop the network and 237 replay valid data packets from the current session it could 238 potentially create some form of denial of service for the user. A 239 good example of such a packet would be a TCP FIN packet (which are 240 very common when using the WEB which have many short-lived 241 connections). Since most TCP implementations do not have random 242 initial sequence numbers, this is a very simple attack. 244 In order to protect against such an attack it is recommended that the 245 L2TP flow control mechanism be enabled on the data path. This will 246 offer protection since a replay packet would only be accepted once 247 the window "rolled" over. 249 3.3 Compromise of the Master Key 250 Since tunnels may be long-lived and frequent, it is possible for the 251 master key to be compromised. A malicious user could gain many valid 252 samples and given enough resources could guess the master key. This 253 is a very serious problem which must be addressed. 255 One simple and effective method to protect against this is to have 256 both L2TP peers generate a session key when a tunnel is created. 257 This key would be transmitted in the Start-Control-Connection-Request 258 and the appropriate -Reply message. Furthermore, an L2TP peer could 259 generate a new key whenever its sequence number "rolls" over. This 260 would create a new security association between both peers, and 261 protect against compromise of the master key. 263 This scheme would also protect against the replay of the data packet 264 described above since the key would be changed once the Sequence 265 number reached zero, making the replayed packet non- authenticated. 267 4.0 AVP Hiding 269 Document [1] states that a shared secret that exists between the 270 tunnel peers is used for the AVP Hiding algorithm. However when using 271 this extension on the control channel, the shared secret is only used 272 to "hide" the initial control and payload channel key. 274 All subsequent AVP hiding uses the key instead of the shared (or 275 master) key (including any other AVPs in the SCCRQ and SCCRP 276 messages). This means that the key renegotiation procedure uses the 277 old key to hide the new key. 279 5.0 Security Association Negotiation 281 This section will define the new message type and AVPs which are 282 required for the security extensions of the L2TP protocol. The AVPs 283 allow designation of a Key for control messages, payload messages, or 284 both. The Keys may or may not be the same for each. 286 5.1 Renegotiate-Security-Association (RSA) 288 The Renegotiate-Security-Association message type is a new L2TP 289 control message used to renegotiate a new security association. It 290 MAY be sent periodically while the control connection is established. 291 To avoid certain replay attacks It SHOULD be sent before the sequence 292 number of a control or call queue "rolls" back to 0. 294 If the CallId field in the L2TP header was set to a zero value, the 295 key is being renegotiated for the control channel. If a non-zero 296 value was found the key is being renegotiated for the payload 297 channel. 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | L2TP Control Message Header | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Renegotiate-Security-Association | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Encoded Control Message Key | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Control Message SPI | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Encoded Payload Packet Key | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Payload Packet SPI | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Renegotiate-Security-Association 315 0 1 2 3 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |1|0|0|0| 8 | 43 | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | 3 | 17 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 The Message Type AVP is encoded with a Vendor ID of 43 (3Com 324 Corporation) with the attribute set to 3, mandatory, indicating 325 Renegotiate-Security-Association. This AVP MUST be present. This 326 message type indicates that the peer wishes to negotiate a new key 327 for the payload stream or control stream. If the message contains 328 a new key for the control channel the message digest function is 329 calculated using the decrypted form of the key found within the 330 Encoded Message Key AVP found in this message. 332 5.2 Encoded Message Key 334 The Encoded Message Key AVP may be present in SCCRQ, SCCRP, OCRQ, 335 OCRP, ICRQ and ICRP. This message is used to inform the tunnel peer 336 of a key to be used for the generation of the MIC (shown above) as 337 well as the hiding of all attributes [1]. 339 The presence of this attribute in the SCCRQ and SCCRP indicates that 340 the key is being setup for the control channel. When found in the 341 OCRQ, OCRP, ICRQ or the ICRP, the key is to be used for the payload 342 channel which is referenced by the Assigned CallId AVP. 344 Note that there is a direct relationship between this key and the SPI 345 value passed in the same message. 347 When a key is being negotiated on the control channel, any AVP hiding 348 MUST use the decrypted form of this key as the shared secret [1]. 350 0 1 2 3 351 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |1|1|0|0| Length | 0 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | 4 | Encoded Message Key... | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 The Message Type AVP is encoded with a Vendor ID of 43 (3Com 359 Corporation) with the attribute set to 4, mandatory, with the 360 indicated number of bytes representing the encoded message key. 361 This AVP MAY be present in the messages shown above. This AVP MUST 362 be hidden and is optional. When present, the L2TP peer is 363 indicating that authentication is required on all control or 364 payload packets. 366 5.3 Message Security Parameter Index 368 The SPI is used as a reference to a session key. The locally 369 generated SPI value MUST be inserted in the SPI field of the L2TP 370 header to reference the appropriate KEY (found in the Encoded Message 371 Key AVP). 373 When renegotiating a new key, a new SPI MUST be generated to 374 correctly identify the key. The old key MUST become invalidated. On 375 the payload channel, the peer MAY retain the old SPI for a short time 376 in order to authenticate packets which are received out of order. 378 0 1 2 3 379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |1|0|0|0| 10 | 43 | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 5 | Control Message SPI... | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | .... (4 bytes) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 The Message Type AVP is encoded with a Vendor ID of 43 (3Com 389 Corporation) with the attribute set to 5, mandatory, with length 390 10. This AVP MUST be present if the Encoded Message Key AVP is 391 present. This AVP is optional and contains the security parameters 392 index for the control or the payload channel. 394 6.0 Acknowledgments 396 We would like to thank Baiju Patel from Intel Coproration for their 397 assistance. 399 7.0 References 401 [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, 402 A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter, 403 A. Rubens "Layer Two Tunneling Protocol (L2TP)", 404 Internet draft, October 1997 406 [2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 407 07/21/1994 409 [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 410 Message Authentication", RFC 2104, February 1997 412 [4] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 413 04/16/1992 415 [5] D. Eastlake III, S. Crocker, J. Schiller, "Randomness 416 Recommendations for Security", RFC 1750, December 1994 418 8.0 Authors' Addresses 420 Questions about this memo can be directed to: 422 Pat R. Calhoun 423 Technology Development 424 Sun Microsystems, Inc. 425 15 Network Circle 426 Menlo Park, California, 94025 427 USA 429 Phone: 1-650-786-7733 430 Fax: 1-650-786-6445 431 E-mail: pcalhoun@eng.sun.com 433 W. Mark Townsley 434 Cisco Systems 435 7025 Kit Creek Road 436 P.O. Box 14987 437 Research Triangle Park, NC 27709 438 USA 439 Phone: 919-472-3741 440 Fax: 919-472-2940 441 E-mail: townsley@cisco.com 443 Sumit A. Vakil 444 VPNet Technologies, Inc. 445 1530 Meridian Ave 446 San Jose, CA 95125 447 USA 449 Phone: 408-445-6600 x264 450 Fax: 408-445-6611 451 E-mail: svakil@vpnet.com 453 Don Grosser 454 IBM Corporation 455 700 Park Office Dr. 456 Research Triangle Park, NC, 27709 457 USA 459 Phone: 919-254-2160 460 E-Mail: grosser@raleigh.ibm.com 462 Appendix A: Additional Recommendations for secure L2TP implementations 464 This appendix identifies some potential security problems with the 465 L2TP and includes reccommendations for ways to avoid the associated 466 risks. We do not identify any new protocol entities here, rather 467 provide implementation advice for greater security when using L2TP. 469 A.1 Proxy CHAP 471 While proxy CHAP provides a useful method of forwarding the challenge 472 issued by the LAC and the response from the client to the LNS for 473 final processing, there is a potential security risk if the operator 474 of the LNS does not FULLY trust the operator of the LAC. Granted, 475 there must be some level of trust between these two entities to setup 476 billing practices, etc. However, allowing the LAC to control the 477 challenge gives the operator of the LAC a very simple (and perhaps 478 tempting) way to impersonate any user which has been tunneled through 479 her system in the past (given that the user's password has not 480 changed in the home network). By simply replaying the 481 challenge/response pair to the LNS in the proxy CHAP AVP, a malicious 482 user can gain access as that user on the home network via the LNS at 483 any time. This impersonated call can continue to exist undetected 484 until a CHAP rechallenge is sent from the LNS to the client at which 485 time the fake client will presumably fail to answer the challege 486 correctly and be disconnected. 488 Neither the protocol specified in this document nor IPSEC can counter 489 against this kind of attack by a malicious, yet "trusted" LAC. 490 However, the LNS can remedy this problem by simply issuing a CHAP 491 rechallenge so that the challenge is issued by the LNS rather than 492 the LAC. This makes it much more difficult for the LAC operator to 493 spoof the CHAP authentication phase at your LNS, reducing 494 vulnerabilty considerably. 496 To implement this security feature, a CHAP rechallenge MUST be issued 497 from the LNS in lieu of sending a CHAP SUCCESS based upon the proxy 498 CHAP values sent from the LAC. If the proxy CHAP values sent from the 499 LAC result in a CHAP FAILURE, there is no compelling reason to send 500 the rechallenge unless you wish to give the client another "chance" 501 at answering the challenge correctly. 503 A.2 Tunnel ID and Call ID selection 505 As suggested in section 2.2, Tunnel IDs and Call IDs SHOULD be 506 selected in a sufficiently random manner rather than sequentially or 507 any other predictable order. Doing so helps prevent a malicious user 508 who otherwise does not have access to packet traces to and from a LAC 509 or LNS to guess the ID of an active session and attempt to hijack it. 511 However, when using the L2TP Security extensions this requirement is 512 no longer required since the level of authentication this extension 513 provides does not allow a malicious user to simply guess a Tunnel and 514 Call Id.