From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2888.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc2888.txt (limited to 'doc/rfc/rfc2888.txt') diff --git a/doc/rfc/rfc2888.txt b/doc/rfc/rfc2888.txt new file mode 100644 index 0000000..53c87d4 --- /dev/null +++ b/doc/rfc/rfc2888.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group P. Srisuresh +Request for Comments: 2888 Campio Communications +Category: Informational August 2000 + + + Secure Remote Access with L2TP + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + L2TP protocol is a virtual extension of PPP across IP network + infrastructure. L2TP makes possible for an access concentrator (LAC) + to be near remote clients, while allowing PPP termination server + (LNS) to be located in enterprise premises. L2TP allows an enterprise + to retain control of RADIUS data base, which is used to control + Authentication, Authorization and Accountability (AAA) of dial-in + users. The objective of this document is to extend security + characteristics of IPsec to remote access users, as they dial-in + through the Internet. This is accomplished without creating new + protocols and using the existing practices of Remote Access and + IPsec. Specifically, the document proposes three new RADIUS + parameters for use by the LNS node, acting as Secure Remote Access + Server (SRAS) to mandate network level security between remote + clients and the enterprise. The document also discusses limitations + of the approach. + +1. Introduction and Overview + + Now-a-days, it is common practice for employees to dial-in to their + enterprise over the PSTN (Public Switched Telephone Network) and + perform day-to-day operations just as they would if they were in + corporate premises. This includes people who dial-in from their home + and road warriors, who cannot be at the corporate premises. As the + Internet has become ubiquitous, it is appealing to dial-in through + the Internet to save on phone charges and save the dedicated voice + lines from being clogged with data traffic. + + + + + + +Srisuresh Informational [Page 1] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + The document suggests an approach by which remote access over the + Internet could become a reality. The approach is founded on the + well-known techniques and protocols already in place. Remote Access + extensions based on L2TP, when combined with the security offered by + IPSec can make remote access over the Internet a reality. The + approach does not require inventing new protocol(s). + + The trust model of remote access discussed in this document is viewed + principally from the perspective of an enterprise into which remote + access clients dial-in. A remote access client may or may not want to + enforce end-to-end IPsec from his/her end to the enterprise. + However, it is in the interest of the enterprise to mandate security + of every packet that it accepts from the Internet into the + enterprise. Independently, remote users may also pursue end-to-end + IPsec, if they choose to do so. That would be in addition to the + security requirement imposed by the enterprise edge device. + + Section 2 has reference to the terminology used throughout the + document. Also mentioned are the limited scope in which some of these + terms may be used in this document. Section 3 has a brief description + of what constitutes remote access. Section 4 describes what + constitutes network security from an enterprise perspective. Section + 5 describes the model of secure remote access as a viable solution to + enterprises. The solution presented in section 5 has some + limitations. These limitations are listed in section 6. Section 7 is + devoted to describing new RADIUS attributes that may be configured to + turn a NAS device into Secure Remote Access Server. + +2. Terminology and scope + + Definition of terms used in this document may be found in one of (a) + L2TP Protocol document [Ref 1], (b) IP security Architecture document + [Ref 5], or (c) Internet Key Exchange (IKE) document [Ref 8]. + + Note, the terms Network Access Server (NAS) and Remote Access + Server(RAS) are used interchangeably throughout the document. While + PPP may be used to carry a variety of network layer packets, the + focus of this document is limited to carrying IP datagrams only. + + "Secure Remote Access Server" (SRAS) defined in this document refers + to a NAS that supports tunnel-mode IPsec with its remote clients. + Specifically, LNS is the NAS that is referred. Further, involuntary + tunneling is assumed for L2TP tunnel setup, in that remote clients + initiating PPP session and the LAC that tunnels the PPP sessions are + presumed to be distinct physical entities. + + + + + + +Srisuresh Informational [Page 2] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + Lastly, there are a variety of transport mediums by which to tunnel + PPP packets between a LAC and LNS. Examples include Frame Relay or + ATM cloud and IP network infrastructure. For simplicity, the document + assumes a public IP infrastructure as the medium to transport PPP + packets between LAC and LNS. Security of IP packets (embedded within + PPP) in a trusted private transport medium is less of a concern for + the purposes of this document. + +3. Remote Access operation + + Remote access is more than mere authentication of remote clients by a + Network Access Server(NAS). Authentication, Authorization, Accounting + and routing are integral to remote access. A client must first pass + the authentication test before being granted link access to the + network. Network level services (such as IP) are granted based on the + authorization characteristics specified for the user in RADIUS. + Network Access Servers use RADIUS to scale for large numbers of users + supported. NAS also monitors the link status of the remote access + clients. + + There are a variety of techniques by which remote access users are + connected to their enterprise and the Internet. At a link level, the + access techniques include ISDN digital lines, analog plain-old- + telephone-service lines, xDSL lines, cable and wireless to name a + few. PPP is the most common Layer-2 (L2)protocol used for carrying + network layer packets over these remote access links. PPP may be used + to carry a variety of network layer datagrams including IP, IPX and + AppleTalk. The focus of this document is however limited to IP + datagrams only. + + L2TP is a logical extension of PPP over an IP infrastructure. While a + LAC provides termination of Layer 2 links, LNS provides the logical + termination of PPP. As a result, LNS becomes the focal point for (a) + performing the AAA operations for the remote users, (b) assigning IP + address and monitoring the logical link status (i.e., the status of + LAC-to-LNS tunnel and the link between remote user and LAC), and (c) + maintaining host-route to remote user network and providing routing + infrastructure into the enterprise. + + L2TP uses control messages to establish, terminate and monitor the + status of the logical PPP sessions (from remote user to LNS). These + are independent of the data messages. L2TP data messages contain an + L2TP header, followed by PPP packets. The L2TP header identifies the + PPP session (amongst other things) to which the PPP packet belongs. + The IP packets exchanged from/to the remote user are carried within + the PPP packets. The L2TP data messages, carrying end-to-end IP + packets in an IP transport medium may be described as follows. The + exact details of L2TP protocol may be found in [Ref 1]. + + + +Srisuresh Informational [Page 3] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + +----------------------+ + | IP Header | + | (LAC <->LNS) | + +----------------------+ + | UDP Header | + +----------------------+ + | L2TP Header | + | (incl. PPP Sess-ID) | + +----------------------+ + | PPP Header | + | (Remote User<->LNS) | + +----------------------+ + | End-to-end IP packet | + | (to/from Remote User)| + +----------------------+ + +4. Requirements of an enterprise Security Gateway + + Today's enterprises are aware of the various benefits of connecting + to the Internet. Internet is a vast source of Information and a means + to disseminate information and make available certain resources to + the external world. However, enterprises are also aware that security + breaches (by being connected to the Internet) can severely jeopardize + internal network. + + As a result, most enterprises restrict access to a pre-defined set of + resources for external users. Typically, enterprises employ a + firewall to restrict access to internal resources and place + externally accessible servers in the DeMilitarized Zone (DMZ), in + front of the firewall, as described below in Figure 1. + + + + + + + + + + + + + + + + + + + + + +Srisuresh Informational [Page 4] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + ---------------- + ( ) + ( ) + ( Internet ) + ( ) + (_______________ ) + + WAN | + .........|\|.... + | + +-----------------+ + |Enterprise Router| + +-----------------+ + | + | DMZ - Network + --------------------------------- + | | | + +--+ +--+ +----------+ + |__| |__| | Firewall | + /____\ /____\ +----------+ + DMZ-Name DMZ-Web ... | + Server Server | + | + ------------------ + ( ) + ( Internal Network ) + ( (private to the ) + ( enterprise) ) + (_________________ ) + + Figure 1: Security model of an Enterprise using Firewall + + Network Access Servers used to allow direct dial-in access (through + the PSTN) to employees are placed within the private enterprise + network so as to avoid access restrictions imposed by a firewall. + + With the above model, private resources of an enterprise are + restricted for access from the Internet. Firewall may be configured + to occasionally permit access to a certain resource or service but is + not recommended on an operational basis as that could constitute a + security threat to the enterprise. It is of interest to note that + even when the firewall is configured to permit access to internal + resources from pre-defined external node(s), many internal servers, + such as NFS, enforce address based authentication and do not co- + operate when the IP address of the external node is not in corporate + IP address domain. In other words, with the above security model, it + + + + + +Srisuresh Informational [Page 5] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + becomes very difficult to allow employees to access corporate + resources, via the Internet, even if you are willing to forego + security over the Internet. + + With the advent of IPsec, it is possible to secure corporate data + across the Internet by employing a Security Gateway within the + enterprise. Firewall may be configured to allow IKE and IPsec packets + directed to a specific Security Gateway behind the firewall. It then + becomes the responsibility of the Security Gateway to employ the + right access list for external connections seeking entry into the + enterprise. Essentially, the access control functionality for IPsec + secure packets would be shifted to the Security Gateway (while the + access control for clear packets is retained with the firewall). The + following figure illustrates the model where a combination of + Firewall and Security Gateway control access to internal resources. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Srisuresh Informational [Page 6] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + ------------ + ( ) + ( ) + ( Internet ) + ( ) + (___________ ) + + WAN | + .........|\|.... + | + +-----------------+ + |Enterprise Router| + +-----------------+ + | + | DMZ - Network + ------------------------------------------------------------ + | | | + +--+ +--+ +----------+ + |__| |__| | Firewall | + /____\ /____\ +----------+ + DMZ-Name DMZ-Web ... | + Server Server etc. | LAN + | + ------------------------------------ + | | + +----------+ +------------------+ + | LNS | | Security Gateway | + | Server | | (SGW) | + +----------+ +------------------+ + | + ------------------ + ( ) + ( Internal Network ) + ( (Private to the ) + ( enterprise) ) + (_________________ ) + + Figure 2: Security Model based on Firewall and Security Gateway + + In order to allow employee dial-in over the Internet, an LNS may be + placed behind a firewall, and the firewall may be configured to allow + UDP access to the LNS from the Internet. Note, it may not be possible + to know all the IP addresses of the LACs located on the Internet at + configuration time. Hence, the need to allow UDP access from any node + on the Internet. The LNS may be configured to process only the L2TP + packets and drop any UDP packets that are not L2TP. + + + + + +Srisuresh Informational [Page 7] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + Such a configuration allows remote access over the Internet. However, + the above setup is prone to a variety of security attacks over the + Internet. It is easy for someone on the Internet to steal a remote + access session and gain access to precious resources of the + enterprise. Hence it is important that all packets are preserved with + IPsec to a security Gateway (SGW) behind the LNS, so the Security + Gateway will not allow IP packets into corporate network unless it + can authenticate the same. + + The trust model of secure remote access assumes that the enterprise + and the end user are trusted domains. Everything in between is not + trusted. Any examination of the end-to-end packets by the nodes + enroute would violate this trust model. From this perspective, even + the LAC node enroute must not be trusted with the end-to-end IP + packets. Hence, location and operation of LAC is not relevant for the + discussion on security. On the other hand, location and operation of + LNS and the Security Gateway (SGW) are precisely the basis for + discussion. + + Having security processing done on an independent Security gateway + has the following shortcomings. + + 1. Given the trust model for remote access, the SGW must be + configured with a set of security profiles, access control lists + and IKE authentication parameters for each user. This mandates an + independent provisioning of security parameters on a per-user + basis. This may not be able to take advantage of the user-centric + provisioning on RADIUS, used by the LNS node. + + 2. Unlike the LNS, SGW may not be in the routing path of remote + access packets. I.e., there is no guarantee that the egress IP + packets will go through the chain of SGW and LNS before they are + delivered to remote user. As a result, packets may be subject to + IPSec in one direction, but not in the other. This can be a + significant threat to the remote access trust model. + + 3. Lastly, the SGW node does not have a way to know when a remote + user node(s) simply died or the LAC-LNS tunnel failed. Being + unable to delete the SAs for users that no longer exist could + drain the resources of the SGW. Further, the LNS cannot even + communicate the user going away to the SGW because, the SGW + maintains its peer nodes based on IKE user ID, which could be + different the user IDs employed by the LNS node. + + + + + + + + +Srisuresh Informational [Page 8] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + +5. Secure Remote Access + + Combining the functions of IPsec Security Gateway and LNS into a + single system promises to offer a viable solution for secure remote + access. By doing this, remote access clients will use a single node + as both (a) PPP termination point providing NAS service, and (b) the + Security gateway node into the enterprise. We will refer this node as + "Secure Remote Access Server" (SRAS). + + The SRAS can benefit greatly from the confluence of PPP session and + IPsec tunnel end points. PPP session monitoring capability of L2TP + directly translates to being able to monitor IPsec tunnels. Radius + based user authorization ability could be used to configure the + security characteristics for IPsec tunnel. This includes setting + access control filters and security preferences specific to each + user. This may also be extended to configuring IKE authentication and + other negotiation parameters, when automated key exchange is + solicited. Security attributes that may be defined in Radius are + discussed in detail in section 7. Needless to say, the centralized + provisioning capability and scalability of Radius helps in the + configuration of IPsec. + + As for remote access, the benefit is one of IPsec security as + befitting the trust model solicited by enterprises for the end-to-end + IP packets traversing the Internet. You may use simply AH where there + is no fear of external eaves-dropping, but you simply need to + authenticate packet data, including the source of packet. You may use + ESP (including ESP-authentication), where there is no trust of the + network and you do not want to permit eaves-dropping on corporate + activities. + + Operation of SRAS requires that the firewall be configured to permit + UDP traffic into the SRAS node. The SRAS node in turn will process + just the L2TP packets and drop the rest. Further, the SRAS will + require all IP packets embedded within PPP to be one of AH and ESP + packets, directed to itself. In addition, the SRAS will also permit + IKE UDP packets (with source and destination ports sets to 500) + directed to itself in order to perform IKE negotiation and generate + IPsec keys dynamically. All other IP packets embedded within PPP will + be dropped. This enforces the security policy for the enterprise by + permitting only the secure remote access packets into the enterprise. + When a PPP session is dropped, the IPsec and ISAKMP SAs associated + with the remote access user are dropped from the SRAS. All the + shortcomings listed in the previous section with LNS and SGW on two + systems disappear withe Secure Remote Access Server. Figure 3 below + is a typical description of an enterprise supporting remote access + users using SRAS system. + + + + +Srisuresh Informational [Page 9] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + ------------ + Remote Access +-------------+ ( ) + +--+______ Link | Local Access| ( ) + |__| /___________| Concentrator|----( Internet ) + /____\ | (LAC) | ( ) + RA-Host +-------------+ (____________) + + WAN | + .........|\|.... + | + +-----------------+ + |Enterprise Router| + +-----------------+ + | + | DMZ - Network + ------------------------------------------ + | | | + +--+ +--+ +----------+ + |__| |__| | Firewall | + /____\ /____\ +----------+ + DMZ-Name DMZ-Web ... | + Server Server etc. | LAN + | + ------------------------------------ + | + +---------------+ + | Secure Remote | + | Access Server | + | (SRAS) | + +---------------+ + | + --------------------- + ( ) + +--+ ( Internal Network ) + |__|------( (Private to the ) + /____\ ( enterprise) ) + Ent-Host (______________________) + + Figure 3: Secure Remote Access Server operation in an Enterprise + + The following is an illustration of secure remote access data flow as + end-to-end IP packets traverse the Internet and the SRAS. The example + shows IP packet tunneling and IPsec transformation as packets are + exchanged between a remote Access host (RA-Host) and a host within + the enterprise (say, Ent-Host). + + + + + + +Srisuresh Informational [Page 10] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + Note, the IP packets originating from or directed to RA-Host are + shown within PPP encapsulation, whereas, all other packets are shown + simply as IP packets. It is done this way to highlight the PPP + packets encapsulated within L2TP tunnel. The PPP headers below are + identified by their logical source and destination in parenthesis. + Note, however, the source and recipient information of the PPP data + is not a part of PPP header. This is described thus, just for + clarity. In the case of an L2TP tunnel, the L2TP header carries the + PPP session ID, which indirectly identifies the PPP end points to the + LAC and the LNS. Lastly, the IPsec Headers section below include the + tunneling overhead and the AH/ESP headers that are attached to the + tunnel. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Srisuresh Informational [Page 11] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + RA-Host to Ent-Host Packet traversal: + ------------------------------------ + + RA-Host LAC SRAS Ent-Host + ===================================================================== + + +----------------------+ + | PPP Header | + | (RA-Host ->SRAS) | + +----------------------+ + | Tunnel-Mode IPsec | + | Hdr(s)(RA-Host->SRAS)| + +----------------------+ + | End-to-end IP packet | + | transformed as needed| + | (RA-Host->Ent-Host) | + +----------------------+ + ----------------------> + + +----------------------+ + | IP Header | + | (LAC->SRAS) | + +----------------------+ + | UDP Header | + +----------------------+ + | L2TP Header | + | (incl. PPP Sess-ID) | + +----------------------+ + | PPP Header | + | (RA-Host ->SRAS) | + +----------------------+ + | Tunnel-Mode IPsec | + | Hdr(s)(RA-Host->SRAS)| + +----------------------+ + | End-to-end IP packet | + | transformed as needed| + | (RA-Host->Ent-Host) | + +----------------------+ + ----------------------> + + +----------------------+ + | End-to-end IP packet | + | (RA-Host->Ent-Host) | + +----------------------+ + ----------------------> + + + + + + +Srisuresh Informational [Page 12] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + Ent-Host to RA-Host Packet traversal: + ------------------------------------ + + Ent-Host SRAS LAC RA-Host + ===================================================================== + + +----------------------+ + | End-to-end IP packet | + | (Ent-Host->Ra-Host) | + +----------------------+ + ----------------------> + + +----------------------+ + | IP Header | + | (SRAS->LAC) | + +----------------------+ + | UDP Header | + +----------------------+ + | L2TP Header | + | (incl. PPP Sess-ID) | + +----------------------+ + | PPP Header | + | (SRAS->RA-Host) | + +----------------------+ + | Tunnel-Mode IPsec | + | Hdr(s)(SRAS->RA-Host)| + +----------------------+ + | End-to-end IP packet | + | transformed as needed| + | (Ent-Host->RA-Host) | + +----------------------+ + ----------------------> + + +----------------------+ + | PPP Header | + | (SRAS->RA-Host) | + +----------------------+ + | Tunnel-Mode IPsec | + | Hdr(s)(SRAS->RA-Host)| + +----------------------+ + | End-to-end IP packet | + | transformed as needed| + | (Ent-Host->RA-Host) | + +----------------------+ + ----------------------> + + + + + + +Srisuresh Informational [Page 13] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + +6. Limitations to Secure Remote Access using L2TP + + The SRAS model described is not without its limitations. Below is a + list of the limitations. + + 1. Tunneling overhead: There is considerable tunneling overhead on + the end-to-end IP packet. Arguably, there is overlap of + information between tunneling headers. This overhead will undercut + packet throughput. + + The overhead is particularly apparent at the LAC and SRAS nodes. + Specifically, the SRAS has the additional computational overhead + of IPsec processing on all IP packets exchanged with remote users. + This can be a significant bottleneck in the ability of SRAS to + scale for large numbers of remote users. + + 2. Fragmentation and reassembly: Large IP packets may be required to + undergo Fragmentation and reassembly at the LAC or the LNS as a + result of multiple tunnel overhead tagged to the packet. + Fragmentation and reassembly can havoc on packet throughput and + latency. However, it is possible to avoid the overhead by reducing + the MTU permitted within PPP frames. + + 3. Multiple identity and authentication requirement: Remote Access + users are required to authenticate themselves to the SRAS in order + to be obtain access to the link. Further, when they require the + use of IKE to automate IPsec key exchange, they will need to + authenticate once again with the same or different ID and a + distinct authentication approach. The authentication requirements + of IKE phase 1 [Ref 8] and LCP [Ref 3] are different. + + However, it is possible to have a single authentication approach + (i.e., a single ID and authentication mechanism) that can be + shared between LCP and IKE phase 1. The Extended Authentication + Protocol(EAP) [Ref 4] may be used as the base to transport IKE + authentication mechanism into PPP. Note, the configuration + overhead is not a drag on the functionality perse. + + 4. Weak security of Link level authentication: As LCP packets + traverse the Internet, the Identity of the remote user and the + password (if a password is used) is sent in the clear. This makes + it a target for someone on the net to steal the information and + masquerade as remote user. Note, however, this type of password + stealing will not jeopardize the security of the enterprise per + se, but could result in denial of service to remote users. An + intruder can collect the password data and simply steal the link, + but will not be able to run any IP applications subsequently, as + the SRAS will fail non-IPsec packet data. + + + +Srisuresh Informational [Page 14] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + A better approach would be to employ Extended Authentication + Protocol (EAP) [Ref 4] and select an authentication technique that + is not prone to stealing over the Internet. Alternately, the LAC + and the SRAS may be independently configured to use IPsec to + secure all LCP traffic exchanged between themselves. + +7. Configuring RADIUS to support Secure Remote Access. + + A centralized RADIUS database is used by enterprises to maintain the + authentication and authorization requirements of the dial-in Users. + It is also believed that direct dial-in access (e.g., through the + PSTN network is) safe and trusted and does not need any scrutiny + outside of the link level authentication enforced in LCP. This belief + is certainly not shared with the dial-in access through the Internet. + + So, while the same RADIUS database may be used for a user directly + dialing-in or dialing in through the Internet, the security + requirements may vary. The following RADIUS attributes may be used to + mandate IPsec for the users dialing-in through the Internet. The + exact values for the attributes and its values may be obtained from + IANA (refer Section 10). + +7.1. Security mandate based on access method + + A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each + user. This attribute may be given one of the following values. + + NONE (=0) No IPsec mandated on the IP packets + embedded within PPP. + + LNS_AS_SRAS (=1) Mandates Tunnel mode IPsec on the IP + packets embedded within PPP, only so + long as the PPP session terminates + at an LNS. LNS would be the tunnel + mode IPsec end point. + + SRAS (=2) Mandates Tunnel mode IPsec on the IP + packets embedded within PPP, + irrespective of the NAS type the PPP + terminates in. I.e., the IPsec mandate + is not specific to LNS alone, and is + applicable to any NAS, terminating + PPP. NAS would be the tunnel mode + IPsec end point. + + + + + + + +Srisuresh Informational [Page 15] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + When IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or SRAS, + that would direct the NAS to drop any IP packets in PPP that are not + associated with an AH or ESP protocol. As an exception, the NAS will + continue to process IKE packets (UDP packets, with source and + destination port set to 500) directed from remote users. Further, the + security profile parameter, defined in the following section may add + additional criteria for which security is not mandatory. + +7.2. Security profile for the user + + A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to + describe security access requirements for the users. The profile + could contain information such as the access control security + filters, security preferences and the nature of Keys (manual or + automatic generated via the IKE protocol) used for security purposes. + + The SECURITY-PROFILE attribute can be assigned a filename, as a + string of characters. The contents of the file could be vendor + specific. But, the contents should include (a) a prioritized list + access control security policies, (b) Security Association security + preferences associated with each security policy. + +7.3. IKE negotiation profile for the user + + If the security profile of a user requires dynamic generation of + security keys, the parameters necessary for IKE negotiation may be + configured separately using a new IKE_NEGOTIATION_PROFILE (93) + parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be + assigned a filename, as a string of characters. The contents of the + file could however be vendor specific. The contents would typically + include (a) the IKE ID of the user and SRAS, (b) preferred + authentication approach and the associated parameters, such as a + pre-shared-key or a pointer to X.509 digital Certificate, and, (c) + ISAKMP security negotiation preferences for phase I. + +8. Acknowledgements + + The author would like to express sincere thanks to Steve Willens for + initially suggesting this idea. The author is also thankful to Steve + for the many informal conversations which were instrumental in the + author being able to appreciate the diverse needs of the Remote + Access area. + + + + + + + + + +Srisuresh Informational [Page 16] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + +9. Security Considerations + + This document is about providing secure remote access to enterprises + via the Internet. However, the document does not address security + issues for network layers other than IP. While the document focus is + on security over the Internet, the security model provided is not + limited to the Internet or the IP infrastructure alone. It may also + be applied over other transport media such as Frame Relay and ATM + clouds. If the transport media is a trusted private network + infrastructure, the security measures described may not be as much of + an issue. The solution suggested in the document is keeping in view + the trust model between a remote user and enterprise. + +10. IANA Considerations + + This document proposes a total of three new RADIUS attributes to be + maintained by the IANA. These attributes IPSEC_MANDATE, + SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE may be assigned the + values 91, 92 and 93 respectively so as not to conflict with the + definitions for recognized radius types, as defined in + http://www.isi.edu/in-notes/iana/assignments/radius-types. + + The following sub-section explains the criteria to be used by the + IANA to assign additional numbers as values to the IPSEC-MANDATE + attribute described in section 7.1. + +10.1. IPSEC-MANDATE attribute Value + + Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in Section + 7.1; the remaining values [3-255] are available for assignment by the + IANA with IETF Consensus [Ref 11]. + +REFERENCES + + [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and + B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August + 1999. + + [2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, April + 1997. + + [3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [4] Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + + + +Srisuresh Informational [Page 17] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + + [5] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload + (ESP)", RFC 2406, November 1998. + + [7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, + November 1998. + + [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", + RFC 2409, November 1998. + + [9] Piper, D., "The Internet IP Security Domain of Interpretation + for ISAKMP", RFC 2407, November 1998. + + [10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + See also http://www.iana.org/numbers.html + + [11] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC + 1968, June 1996. + + [13] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, + Version 2 (DESE-bis)", RFC 2419, September 1998. + +Author's Address + + Pyda Srisuresh + Campio Communications + 630 Alder Drive + Milpitas, CA 95035 + U.S.A. + + Phone: +1 (408) 519-3849 + EMail: srisuresh@yahoo.com + + + + + + + + + + + + + +Srisuresh Informational [Page 18] + +RFC 2888 Secure Remote Access with L2TP August 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Srisuresh Informational [Page 19] + -- cgit v1.2.3