idnits 2.17.1 draft-ietf-pppext-l2tp-security-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document 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? == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 18 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 584 has weird spacing: '...imed to perta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: '8' is defined on line 527, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 536, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 542, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1969 (ref. '11') (Obsoleted by RFC 2419) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Baiju Patel 2 INTERNET-DRAFT Intel 3 Category: Standards Track Bernard Aboba 4 William Dixon 5 October 1999 Glen Zorn 6 Microsoft 8 Securing L2TP using IPSEC 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 The distribution of this memo is unlimited. It is filed as and expires April 25, 2000. Please send 28 comments to the authors. 30 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 This document discusses how L2TP may utilize IPSEC to provide for tunnel 37 authentication, privacy, and integrity and replay protection. Both the 38 voluntary and compulsory tunneling cases are discussed. 40 Requirements language 42 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 43 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 44 described in [2]. 46 Terminology 48 Voluntary Tunneling 49 In voluntary tunneling, a tunnel is created by the user, 50 typically via use of a tunneling client. As a result, the 51 client will send L2TP packets to the NAS which will forward 52 them on to the LNS. In voluntary tunneling, the NAS does not 53 need to support L2TP, and the LAC resides on the same machine 54 as the remote PPP peer. 56 Compulsory Tunneling 57 In compulsory tunneling, a tunnel is created without any 58 action from the user and without allowing the user any choice. 59 As a result, the user will send PPP packets to the NAS/LAC, 60 which will encapsulate them in L2TP and tunnel them to the 61 LNS. In the compulsory tunneling case, the NAS/LAC must be 62 L2TP capable. 64 1. Introduction 66 L2TP, described in [1], is a protocol that tunnels PPP traffic over 67 variety of networks (e.g., IP, SONET, ATM). Since the protocol 68 encapsulates PPP, L2TP inherits PPP authentication, as well as the PPP 69 Encryption Control Protocol (ECP) [10], and the Compression Control 70 Protocol (CCP) [9]. L2TP also includes support for tunnel 71 authentication, which can be used to mutually authenticate the tunnel 72 endpoints. However, L2TP does not define tunnel protection mechanisms. 74 IPSEC is a protocol suite defined by IETF working group on IP security 75 to secure communication at the network layer between communicating 76 peers. This protocol is comprised of IP Security Architecture document 77 [6], the Internet key exchange (IKE) [7], the IP authentication header 78 (AH) [3] and the IP encapulating security payload (ESP) [4]. IKE is the 79 key management protocol while AH and ESP are used to protect IP traffic. 81 This draft proposes use of the IPSEC protocol suite for protecting L2TP 82 traffic over IP and on-IP networks, and discusses how IPSEC and L2TP 83 should be used together. This document does not attempt to standardize 84 end-to-end security. When end-to-end security is required, it is 85 recommended that additional security mechanisms (such as IPSEC or TLS) 86 be used inside the tunnel, in addition to L2TP tunnel security. 88 2. L2TP security requirements 90 L2TP tunnels PPP traffic over both IP and non-IP public networks. 91 Therefore, both the control and data packets of L2TP protocol are 92 vulnerable to attack. Examples of attacks include: 94 1. The adversary may try to discover user identities by snooping data 95 packets. 97 2. The adversary may try to modify packets (both control and data). 99 3. The adversary may try to hijack the L2TP tunnel or the PPP connection 100 inside the tunnel. 102 4. An adversary can launch denial of service attacks by terminating PPP 103 connections, or L2TP tunnels. 105 5. An adversary may attempt to disrupt the PPP ECP negotiation in order 106 to weaken or remove confidentiality protection. Alternatively, an 107 adversary may wish to disrupt the PPP LCP authentication negotiation so 108 as to weaken the PPP authentication process or gain access to user 109 passwords. 111 To address these threats, the L2TP security protocol MUST be able to 112 provide authentication, integrity and replay protection for control 113 packets. In addition, it SHOULD be able to protect confidentiality of 114 control packets. It MUST be able to provide integrity and replay 115 protection of data packets, and MAY be able to protect confidentiality 116 of data packets. An L2TP security protocol MUST also provide a scalable 117 approach to key management. 119 The L2TP protocol, and PPP authentication and encryption do not meet the 120 security requirements for L2TP. L2TP authentication typically mutually 121 authenticates LAC to LNS at tunnel origination and may periodically re- 122 authenticate. Therefore, it does not protect control and data traffic 123 on a per packet basis. Thus, L2TP tunnel authentication leaves the L2TP 124 tunnel vulnerable to attack. PPP authenticates the client to the LNS, 125 but also does not provide per-packet authentication, integrity, or 126 replay protection. PPP encryption meets confidentiality requirements 127 for PPP traffic but does not address the authentication, integrity and 128 key management requirements. In addition, PPP ECP negotiation, outlined 129 in [10] does not provide for a protected ciphersuite negotiation. 130 Therefore, PPP encryption provides a weak security solution, and in 131 addition does not assist in securing L2TP control channel. 133 Key management facilities are not provided by the L2TP protocol. 134 However, where L2TP tunnel authentication is desired, it is necessary to 135 distribute tunnel passwords. 137 Note that several of the attacks outlined above can be carried out on 138 PPP packets sent over the link between the remote PPP peer and the 139 NAS/LAC, prior to encapsulation of the packets within an L2TP tunnel. 140 While strictly speaking these attacks are outside the scope of L2TP 141 security, in order to protect against them, the PPP peer SHOULD provide 142 for confidentiality, authentication and integrity protection for PPP 143 packets sent over the dial-up link. Authentication and integrity 144 protection are not currently supported by PPP encryption methods, 145 described in [11]-[13]. 147 2.1. L2TP Security Protocol 149 The L2TP security protocol MUST provide authentication, integrity and 150 replay protection for control packets. In addition, it SHOULD protect 151 confidentiality of control packets. It MUST provide integrity and 152 replay protection of data packets, and MAY protect confidentiality of 153 data packets. An L2TP security protocol MUST also provide a scalable 154 approach to key management. 156 To meet the above requirements, all L2TP security compliant 157 implementations MUST implement IPSEC ESP for securing L2TP control 158 packets and SHOULD implement IPSEC ESP for protection of L2TP data 159 packets. All mandated cipher suites, including NULL encryption, of 160 IPSEC ESP MUST be supported. Note that if confidentiality is not 161 required (e.g., L2TP data traffic), ESP with NULL encryption may be 162 used. The implementations MUST implement replay protection mechanisms 163 of IPSEC. 165 L2TP security MUST meet the key management requirements of the IPSEC 166 protocol suite. IKE SHOULD be supported for authentication, security 167 association negotiation, and key management using the IPSEC DOI [5]. 169 2.2. Stateless compression and encryption 171 Stateless encryption and/or compression is highly desirable when L2TP is 172 run over IP. Since L2TP is a connection-oriented protocol, use of 173 stateful compression/encryption is feasible, but when run over IP, this 174 is not desirable. While providing better compression, and somewhat more 175 secure encryption, when used without an underlying reliable delivery 176 mechanism stateful methods magnify packet losses, and thus are 177 problematic when used over the Internet where packet loss can be 178 significant. In addition, although L2TP is connection oriented, the 179 L2TP specification [1] does not mandate packet ordering, which can 180 create difficulties in implementation of stateful compression/encryption 181 schemes. However, these considerations are not as important when L2TP 182 is run over non-IP media such as ATM, X.25, or Frame Relay, since these 183 media guarantee ordering, and packet losses are typically low. 185 2.3. Implementation considerations for L2TP over Non-IP networks 187 L2TP requires that a non-IP network supports packet transport, so that 188 the non-IP network should be able to carry L2TP control and data 189 packets. 191 Since ESP functions are defined on the IP payload (excluding the IP 192 header), the presence of an IP header is not a requirement for use of 193 ESP. Therefore, L2TP implemented on non-IP networks MUST be able to 194 transport IPSEC ESP packets. The "next payload" field of the ESP header 195 MUST be set to the L2TP protocol number. IANA has assigned 115 as the 196 protocol number for L2TP. 198 IKE messages use UDP transport. Therefore, in order to be compliant 199 with the IKE protocol on non-IP media, the non-IP media (which is 200 capable of transporting packets) MUST support transport of UDP 201 datagrams. Since the IP header is not present in the UDP datagram over 202 non-IP media, the UDP checksum MUST be set to zero by the source and 203 ignored by the destination. 205 The exact mechanisms for enabling transport of ESP and UDP packets over 206 non-IP media MUST be addressed in appropriate standards for L2TP over 207 specific non-IP networks. 209 3. L2TP/IPSEC interoperability guidelines 211 The following guidelines are established to meet L2TP security 212 requirements using IPSEC in practical situations. Note that this section 213 is not a requirement for an implementation to be L2TP security 214 compliant. Its purpose to make the implementors aware of certain 215 efficiency and security considerations. 217 In the scenarios that follow, it is assumed that both L2TP clients and 218 servers are able to set and get the properties of IPSEC security 219 associations, as well as to influence the IPSEC security services 220 negotiated. Furthermore, it is assumed that L2TP clients and servers 221 are able to influence the negotiation process for PPP encryption and 222 compression. 224 3.1. Compulsory tunnel 226 In the case of a compulsory tunnel, the dial-in host will be sending PPP 227 packets to the LAC, and will typically not be aware that its packets are 228 being tunneled, nor that any security services are in place between the 229 LAC and LNS. From the point of view of the LNS, it will note arrival of 230 a PPP data packet encapsulated in L2TP, which is itself encapsulated in 231 an IP packet. Assuming that the LNS is able to retrieve the properties 232 of the Security Association set up between itself and the LAC, it will 233 have knowledge of the security services in place between the LAC and 234 itself. Thus in the compulsory tunneling case, the dial-in host and the 235 LNS have unequal knowledge of the security services in place between 236 them. 238 Since the LNS is capable of knowing whether confidentiality, 239 authentication, integrity and replay protection are in place between the 240 LAC and itself, it can use this knowledge in order to modify its 241 behavior during PPP ECP and CCP negotiation. For example, let us assume 242 that LNS confidentiality policy can be described by one of the following 243 terms: "Require Encryption," "Allow Encryption" or "Prohibit 244 Encryption". If IPSEC confidentiality services are in place, then an 245 LNS implementing a "Prohibit Encryption" policy will act as though the 246 policy had been violated. Similarly, an LNS implementing a "Require 247 Encryption" or "Allow Encryption" policy will act as though these 248 policies were satisfied, and would not mandate use of PPP encryption or 249 compression. Note however, that this is not the same as insisting that 250 PPP encryption and compression be turned off, since this decision will 251 depend on the policy of the dial-in host. 253 Since the dial-in host has no knowledge of the security services in 254 place between the LAC and the LNS, and since it may not trust the LAC or 255 the wire between itself and the LAC, the dial-in host might want to 256 ensure sufficient security through use of end-to-end IPSEC or PPP 257 encryption/compression between itself and the LNS. 259 A dial-in host wishing to ensure security services over the entire 260 travel path would not modify this behavior even if it had knowledge of 261 the security services in place between the LAC and the LNS. This is 262 because the dial-in host needs to negotiate confidentiality services 263 between itself and the LNS in order to provide privacy on the wire 264 between itself and the LAC. Similarly, the dial-in host needs to 265 negotiate end-to-end security between itself and the endstation in order 266 to ensure confidentiality on the portion of the path between the LNS and 267 the endstation. 269 Given that the dial-in host will typically not trust the LAC and will 270 negotiate confidentiality and compression services on its own, the LAC 271 may only wish to negotiate IPSEC ESP with null encryption (described in 272 [14]) with the LNS, and the LNS will request replay protection. This 273 will ensure that confidentiality and compression services will not be 274 duplicated over the path between the LAC and the LNS. This will 275 typically result in better scalability for the LAC, since encryption 276 will be handled by the dial-in host and the LNS. 278 The dial-in host can satisfy the need for confidentiality services in 279 one of two ways. If it knows that all endstations that it will 280 communicate with are IPSEC-capable (or if it refuses to talk to non- 281 IPSEC capable endstations), then it can refuse to negotiate PPP 282 encryption/compression and negotiate IPSEC ESP with the endstations 283 instead. If the host does not know that all endstations it will contact 284 are IPSEC-capable (the most likely case), then it will negotiate PPP 285 encryption/compression. This may result in duplicate 286 compression/encryption which can only be eliminated if PPP 287 compression/encryption can be turned off on a per-packet basis. Note 288 that since the LNS knows that the dial-in host's packets are being 289 tunneled but the dial-in host does not, the LNS can ensure that 290 stateless compression/encryption is used by offering stateless 291 compression/encryption methods if available in the ECP and CCP 292 negotiations. 294 3.2. Voluntary tunnel 296 In the case of a voluntary tunnel, the dial-in host will be sending L2TP 297 packets to the NAS, which will route them to the LNS. Over a dial-up 298 link, these L2TP packets will be encapsulated in IP and PPP. Assuming 299 that it is possible for the dial-in host to retrieve the properties of 300 the Security Association between itself and the LNS, the dial-in host 301 will have knowledge of any security services negotiated between itself 302 and the LNS. It will also have knowledge of PPP encryption/compression 303 services negotiated between itself and the NAS. 305 >From the LNS's point of view, it will note a PPP packet encapsulated in 306 L2TP, which is itself encapsulated in an IP frame. This situation is 307 identical to the compulsory tunneling case. Assuming that the LNS is 308 able to retrieve the properties of the Security Association set up 309 between itself and the dial-in host, it will have knowledge of the 310 security services in place between the dial-in user and itself. Thus in 311 the voluntary tunneling case, the dial-in host and the LNS have 312 symmetric knowledge of the security services in place between them. 314 Since the LNS is capable of knowing whether confidentiality, 315 authentication, integrity check and replay protection is in place 316 between the dial-in host and itself, it is able to use this knowledge to 317 modify its PPP ECP and CCP negotiation stance. If IPSEC confidentiality 318 is in place, the LNS can behave as though a "Require Encryption" 319 directive had been fulfilled, not mandating use of PPP encryption or 320 compression. Typically the LNS will not insist that PPP 321 encryption/compression be turned off, instead leaving this decision to 322 the dial-in host. 324 Since the dial-in host has knowledge of the security services in place 325 between itself and the LNS, it can act as though a "Require Encryption" 326 directive had been fulfilled if IPSEC ESP was already in place between 327 itself and the LNS. Thus, it can request that PPP encryption and 328 compression not be negotiated. Note that if IP compression services 329 cannot be negotiated, it will typically be desirable to turn off PPP 330 compression if no stateless method is available, due to the undesirable 331 effects of stateful PPP compression. 333 Thus in the voluntary tunneling case the dial-in host and LNS will 334 typically be able to avoid use of PPP encryption and compression, 335 negotiating IPSEC confidentiality, authentication, and integrity 336 protection services instead, as well as IP compression (if available). 338 This may result in duplicate encryption if the dial-in host is 339 communicating with an IPSEC-capable endstation. In order to avoid 340 duplicate encryption/compression, the dial-in host may open two tunnels 341 with the LNS, each using a seperate security association. One SA would 342 use ESP with null encryption or AH, while the other would negotiate 343 confidentiality/compression. Packets going to an IPSEC-capable 344 endstation would run over the ESP with null encryption security 345 association (and associated L2TP tunnel), and packets to a non-IPSEC 346 capable endstation would run over the other tunnel/SA. This 347 configuration would probably require host routes i (either dynamic or 348 static) to be installed on the dial-in host. 350 Also note that the dial-in host may wish to put confidentiality services 351 in place for non-tunneled packets travelling between itself and the NAS. 352 This will protect the dial-in user against eavesdropping on the wire 353 between itself and the NAS. As a result, it may wish to negotiate PPP 354 encryption and compression with the NAS. As in compulsory tunneling, 355 this will result in duplicate encryption and possibly compression unless 356 PPP compression/encryption can be turned off on a per-packet basis. 358 4. IKE negotiation of L2TP filters 360 When using IKE Identity Protect Mode (Main Mode then Quick Mode 361 exchanges), the IKE quick mode is used to negotiate an IPSEC security 362 association for the protocol and port combination about to be used by 363 L2TP. The 5-tuple filter specification is passed by the initiator 364 during either Quick Mode ID Payload. 366 L2TP implementations MAY use a dynamically assigned UDP source port, but 367 SHOULD use an initial destination port of 1701. L2TP implementations 368 MAY use UDP port 1701 as both source and destination port number. 370 When using pre-shared key authentication, a specific filter for each LAC 371 IP must be present for the LNS to accept incoming IKE L2TP SA requests. 372 Filter matching is most specific for the 5-tuple. When using 373 certificate authentication, an LNS can be configured to access 374 negotiations from any LAC. The LAC would request certificate 375 authentication in the first main mode packet. The LAC and LNS MAY use 376 IKE certificate request payloads (CRP) to agree on a certificate 377 credential to use. 379 Similarly, when certificate authentication is used an L2TP LAC doing 380 compulsory tunneling can be configured to initiate an IKE L2TP SA 381 request to any LNS. However when using pre-shared key authentication, a 382 specific filter for each destination IP must be present to initiate 383 outgoing IKE L2TP SA requests. 385 L2TP LACs SHOULD negotiate the IPSEC security association before sending 386 the first L2TP UDP packet in order to avoid a race condition between the 387 time that the LAC is capable of sending secured packets using the new 388 IPSEC SA, and the time that the LNS would receive the secured packet. 389 If the LNS is very busy, it may take some time before it can install the 390 new IPSEC security association into its inbound IPSEC packet processor. 391 Also, L2TP round trip tunnel negotiation time will be adversely affected 392 if this time also includes the IPSEC IKE negotiation time. 394 4.1. Voluntary Tunnels 396 LNS Filters (certificate authentication): 398 >From to , protocol UDP, source port 1701, dest port Any 399 >From to , protocol UDP, source port Any, dest port 1701 401 LNS Filters (pre-shared key authentication): 403 >From to , protocol UDP, source port 1701, dest port Any 404 >From to , protocol UDP, source port Any, dest port 1701 406 LAC Filters (any method): 408 >From to , protocol UDP, source port Any, dest port 1701 409 >From to , protocol UDP, source port 1701, dest port Any 411 The LAC filter From to is needed to ensure that if the 412 LNS were to initiate rekey of quick mode first, thus proposing this 413 filter in the quick mode ID payload to the client, that the client would 414 accept it. 416 4.2. Compulsory Tunnels 418 LNS Filters (certificate authentication): 420 >From to , protocol UDP, source port 1701, dest port Any 421 >From to , protocol UDP, source port Any, dest port 1701 423 LNS Filters (pre-shared key authentication): 425 >From to , protocol UDP, source port 1701, dest port Any 426 >From to , protocol UDP, source port Any, dest port 1701 428 LAC Filters (certificate authentication): 430 >From to , protocol UDP, source port Any, dest port 1701 431 >From to , protocol UDP, source port 1701, dest port Any 433 LAC Filters (pre-shared key authentication): 435 >From to , protocol UDP, source port Any, dest port 1701 436 >From to , protocol UDP, source port 1701, dest port Any 438 4.3. Gateway-gateway filters 440 In the gateway-gateway case either side may initiate the tunnel so that 441 the filters are symmetric. Since in this case the tunnel endpoints are 442 typically known to each other beforehand, specific filters are used for 443 the endpoints, and so that they can be used with either pre-shared key 444 or certificate authentication. 446 Gateway Filters (any method): 448 1. From IP to , protocol UDP, source port Any, dest port 1701 449 2. From IP to , protocol UDP, source port Any, dest port 1701 450 3. From IP to , protocol UDP, source port 1701, dest port Any 451 4. From IP to , protocol UDP, source port 1701, dest port Any 453 Filters 1 and 2 handle outbound L2TP tunnel initiation traffic when the 454 source port is dynamically mapped and cause the destination to agree to 455 terminate an L2TP tunnel when the source initiates, so as to filter L2TP 456 clear text inbound. Filter 3 and 4 secure the outbound traffic from the 457 destination to the source when the source initiates with dynamically 458 assigned source port. 460 Note: An LNS which is terminating both voluntary tunnels (from Any 461 Source IP address) and gateway-gateway L2TP SA requests MAY use the same 462 filter to accept both voluntary client and gateway L2TP SA requests when 463 using certificate authentication and CRPs to negotiate specific 464 certificate credentials. 466 5. Security considerations 468 IPSEC IKE negotiation MUST negotiate an authentication method specified 469 in the IKE RFC 2409 [7]. 471 When X.509 certificate authentication is chosen, the LNS is expected to 472 use an IKE Certificate Request Payload (CRP) to request from the client 473 a certificate issued by a particular certificate authority or may use 474 several CRPs if several certificate authorities are trusted and 475 configured in its IPSEC IKE authentication policy. The certificate 476 credentials provided by the L2TP client during the IKE negotiation MAY 477 be those of the machine or of the L2TP user. When the L2TP user 478 certificate is used, the client MUST ensure that only traffic from that 479 particular user is sent down the L2TP tunnel. 481 The LNS SHOULD be able to trust several certificate authorities in order 482 to allow tunnel client end-points to connect to it using their own 483 certificate credential from their chosen PKI. Client and server side 484 certificate revocation list checking MAY be enabled on a per-CA basis, 485 since differences in revocation list checking exist between different 486 PKI providers. 488 L2TP implementations MAY use dynamically assigned ports for both source 489 and destination ports only if security for each source and destination 490 port combinations can be successfully negotiated by IKE. 492 A single preshared key for all IKE authentication to an LNS SHOULD NOT 493 be used. IKE pre-shared authentication key values SHOULD be protected 494 in a manner similar to the password used by L2TP for tunnel 495 authentication. 497 6. Acknowledgements 499 Thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay 500 Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco for 501 many useful discussions of this problem space. 503 7. References 505 [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 506 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 507 1999. 509 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 510 Levels", BCP 14, RFC 2119, March 1997. 512 [3] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 513 November 1998. 515 [4] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 516 RFC 2406, November 1998. 518 [5] Piper, D., "The Internet IP Security Domain of Interpretation of 519 ISAKMP", RFC 2407, November 1998. 521 [6] Atkinson, R., Kent, S., "Security Architecture for the Internet 522 Protocol", RFC 2401, November 1998. 524 [7] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 525 2409, November 1998. 527 [8] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 528 RFC 1661, July 1994. 530 [9] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 531 June 1996. 533 [10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, 534 June 1996. 536 [11] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol (DESE)", 537 RFC 1969, June 1996. 539 [12] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 540 (DESE-bis)", RFC 2419, September 1998. 542 [13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 543 2420, September 1998. 545 [14] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its Use 546 With IPsec", RFC 2410, November 1998 548 8. Authors' Addresses 550 Baiju V. Patel 551 Intel Corp 552 2511 NE 25th Ave 553 Hillsboro, OR 97124 555 Phone: 503-264-2422 556 Email: baiju.v.patel@intel.com 558 Bernard Aboba 559 Microsoft Corporation 560 One Microsoft Way 561 Redmond, WA 98052 563 Phone: 425-936-6605 564 EMail: bernarda@microsoft.com 566 William Dixon 567 Microsoft Corporation 568 One Microsoft Way 569 Redmond, WA 98052 570 Phone: 425-703-8729 571 EMail: wdixon@microsoft.com 573 Glen Zorn 574 Microsoft Corporation 575 One Microsoft Way 576 Redmond, WA 98052 578 Phone: 425-703-1559 579 EMail: gwz@acm.org 581 9. Intellectual Property Statement 583 The IETF takes no position regarding the validity or scope of any 584 intellectual property or other rights that might be claimed to pertain 585 to the implementation or use of the technology described in this 586 document or the extent to which any license under such rights might or 587 might not be available; neither does it represent that it has made any 588 effort to identify any such rights. Information on the IETF's 589 procedures with respect to rights in standards-track and standards- 590 related documentation can be found in BCP-11. Copies of claims of 591 rights made available for publication and any assurances of licenses to 592 be made available, or the result of an attempt made to obtain a general 593 license or permission for the use of such proprietary rights by 594 implementors or users of this specification can be obtained from the 595 IETF Secretariat. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary rights 599 which may cover technology that may be required to practice this 600 standard. Please address the information to the IETF Executive 601 Director. 603 10. Full Copyright Statement 605 Copyright (C) The Internet Society (1999). All Rights Reserved. 606 This document and translations of it may be copied and furnished to 607 others, and derivative works that comment on or otherwise explain it or 608 assist in its implmentation may be prepared, copied, published and 609 distributed, in whole or in part, without restriction of any kind, 610 provided that the above copyright notice and this paragraph are included 611 on all such copies and derivative works. However, this document itself 612 may not be modified in any way, such as by removing the copyright notice 613 or references to the Internet Society or other Internet organizations, 614 except as needed for the purpose of developing Internet standards in 615 which case the procedures for copyrights defined in the Internet 616 Standards process must be followed, or as required to translate it into 617 languages other than English. The limited permissions granted above are 618 perpetual and will not be revoked by the Internet Society or its 619 successors or assigns. This document and the information contained 620 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 621 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 622 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 623 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 626 11. Expiration Date 628 This memo is filed as , and 629 expires April 25, 2000.