IPsec Remote Access Working Group Scott Kelly INTERNET-DRAFT RedCreek Communications draft-kelly-ipsra-eval-00.txt July, 2001 Comparing Proposed Solutions for IPsec Remote Access Legacy User Authentication Status of This Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments on this document should be sent to the IETF IPsec remote access discussion list (ietf-ipsra@vpnc.org). Abstract A number of competing methods for integrating legacy remote access user authentication into IPsec have been proposed, resulting in confusion as to which method(s) might be best for solving the problems at hand. This document briefly compares these proposals in an effort to clarify the relative standing of each with respect to the problem space and requirements. Kelly Expires Jan 2002 [Page 1] Internet Draft July, 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Basic Problem Space Description . . . . . . . . . . . . . . . . 3 1.3 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4 1.5 General Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. General Solution Requirements . . . . . . . . . . . . . . . . . . 5 3. Brief Enumeration of Proposed Solutions . . . . . . . . . . . . . 7 4. Common Features of Proposed Solutions . . . . . . . . . . . . . . 8 4.1 Common Issues for Proposals Supporting Preshared Keys . . . . . 8 4.1.1 General issues for configurations using preshared keys . . . . 9 4.1.2 Fixed Address (unique PSK) . . . . . . . . . . . . . . . . . . 10 4.1.2 Non-fixed Address, Global Preshared Key . . . . . . . . . . . 10 4.1.3 Non-fixed Address, Unique Preshared Key . . . . . . . . . . . 11 4.2 General Issues For Configurations Using Mutual Certificates . . 11 5. Comparing the Proposals . . . . . . . . . . . . . . . . . . . . . 12 5.1 XAUTH/MODECFG . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 ULA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4 CRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6 PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.7 GetCert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Comparison of Proposals to Requirements . . . . . . . . . . . . . 17 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1 DoS Susceptibility . . . . . . . . . . . . . . . . . . . . . . . 20 7.2 Code Complexity . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3 Single Sign-on Support . . . . . . . . . . . . . . . . . . . . . 21 7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 23 Kelly Expires Jan 2002 [Page 2] Internet Draft July, 2001 1. Introduction The IPsec remote access working group (ipsra) was formed in order to settle upon a solution set for providing secure remote access using IPsec components. Integral to the secure remote access problem is the desire to provide support for existing legacy authentication mechanisms, most notably RADIUS and SecureID. A number of competing methods for integrating such user authentication into IPsec have been proposed, resulting in confusion as to which method(s) might be best for solving the problems at hand. This document briefly compares these proposals in an effort to clarify the relative standing of each with respect to the problem space and requirements. 1.2 Basic Problem Space Description Customers want to provide secure remote access to their networks using IPsec along with authentication methods which leverage currently deployed user authentication mechanisms (primarily RADIUS and SecureID). This is difficult, as currently defined authentication mechanisms for IPsec are symmetric, e.g. either both sides (the user and the security gateway) authenticate using a shared secret, or both sides authenticate using identical public key mechanisms (encryption or signatures). These mechanisms provide no support for the passphrases which are typically required for legacy mechanisms. While at first glance one might conclude that passwords are similar to shared secrets, and that some adaptation of the shared secret mechanism currently supported by IPsec would resolve this problem, there are at least two issues with this approach (ignoring for the moment that preshared keys are susceptible to dictionary attacks, and that users would often make this simpler by choosing easily guessed passphrases). First, there is the problem of identifying the correct secret to apply at the gateway. IKE, as currently defined, may only identify shared secrets by IP address if main mode is used, and for most remote access scenarios, the IP address of the remote user simply is not known a priori. Even if it were, this would be no help if a one time passphrase mechanism were in use. This implies that use of aggressive mode is required for this approach, and this raises a number of security issues due to vulnerabilities associated with aggressive mode. Also, many of the same issues relating to one time passphrases exist for aggressive mode. The second issue raised by using passphrases as preshared keys pertains to scalability. If passphrases are to be in any way useful from a security perspective, they must be unique for each user. Since Kelly Expires Jan 2002 [Page 3] Internet Draft July, 2001 the gateway must also use this same passphrase (it is being used as a shared secret), this requires that the gateway be configured with each remote user's unique identifier and passphrase. This becomes problematic as the number of remote users grows large. Further complicating matters, legacy mechanisms typically provide one-sided authentication for the user, implicitly trusting that the challenger (the gateway) is who/what it claims to be. However, IPsec provides for no such one-sided authentication technique. Hence, in order to support legacy authentication mechanisms within IPsec, it must either be possible to authenticate the user and the gateway asymmetrically, or it must be possible to derive a user credential from the legacy authentication process which may then be used to secure an IPsec connection. 1.3 Reader Prerequisites Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to understanding the concepts discussed here. Familiarity with concepts relating to Public Key Infrastructures (PKIs) is also necessary, as is familiarity with the various secure remote access proposals discussed below ([XAUTH/MODECFG], [HYBRID], [ULA], [CRACK], [PIC], [L2TPSEC], [GETCERT]). An understanding of various classes of attacks on cryptographic primitives and network connections will further facilitate understanding. 1.4 Requirements Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. 1.5 General Terminology Following are definitions of terms as they are used in this document. o MiM: Man-in-the-Middle, as in the case where an adversary positions an intercepting system between two endpoints, and traffic in both directions must pass through this intercepting system, giving the adversary the opportunity to modify the data stream in either or both directions. o DoS: Denial of Service, as in the case where a system is prevented from delivering essential services due to outside interference. Kelly Expires Jan 2002 [Page 4] Internet Draft July, 2001 o User Identifier: this term refers to the value used to uniquely identify the remote user, typically a user name. o Passphrase: this term refers to the value the remote user presents in conjunction with the user identifier in order to verify the user's identity; it may be a value the user commits to memory (such as an ascii string), it may be retrieved from storage, or it may be generated by a device the user possesses or interacts with at the time of the access attempt. In the case of n-factor authentication mechanisms, a user may be required to present multiple passphrases in order to satisfy admission criteria. o SGW - Security GateWay, the IPsec termination point for the target network to which remote acess is to be provided. o PSK - PreShared Key, as in a shared secret value used for proof of identity and/or group membership. o IRAC - Ipsec Remote Access Client o IRAS - Ipsec Remote Access Server (or SGW) o DH exchange - Diffie-Hellman key exchange 2. General Solution Requirements In evaluating the various proposed solutions, the first order of business is to hold them up against the user authentication requirements for secure remote access to determine how completely satisfied the requirements are by each proposal. Basic requirements for user authentication as it applies to secure remote access using IPsec are presented in [KR01], and these requirements are not detailed here, except for a brief synopsis (taken from [KR01]). In general, proposed IPsec remote access mechanisms should meet the following goals: o should provide direct support for legacy user authentication systems such as RADIUS o should encourage migration from existing low-entropy password-based systems to more secure authentication systems o if legacy support cannot be provided without some sort of migration, the impact of such migration should be minimized o user authentication information must be protected against Kelly Expires Jan 2002 [Page 5] Internet Draft July, 2001 eavesdropping and replay (including the user identity) o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy o n-factor authentication mechanisms should be supported Two additional goals not listed above are suggested in this document: o Security gateway vulnerability to DoS attacks should be minimized, and if possible, should not be greater than the vulnerability which exists in SGW systems not providing remote access o The chosen mechanism(s) should minimize any reduction in the baseline security of the underlying IPsec connection In most cases, the motivation for each of the security goals in the initial list above is obvious. However, the need for the two additional suggested goals may be less evident, so supporting discussion is provided below. Regarding vulnerability to DoS attacks, we should note that the SGW represents a shared access point for the target network, and as such, has the potential to adversely affect multiple users in case of failure, both inside and outside of the target network. Further, in cases where there is only one SGW for a given network, it represents a single point of failure. Hence, it seems reasonable to suggest that the chosen solution should not increase the DoS vulnerability of this critical system if this can be avoided. Regarding the security of the underlying connection, IPsec, as currently defined, provides for a baseline measure of security with certain assumptions. That is, if we may assume that the keying material generated by the DH exchange is effectively random (i.e. unguessable), and by implication that the keying material used for authenticating the key exchange is effectively random (as well as securely stored), then other assumptions regarding relative security of the resulting connection (i.e. the effort required to compromise the connection) are warranted. However, it is possible to choose methods of producing and/or storing authentication keying material which invalidate these assumptions. If such a method is chosen, then the baseline security of the underlying connection will be reduced when compared to a connection which uses more secure keying material production and storage methods. This implies that the overall security characteristics of the user Kelly Expires Jan 2002 [Page 6] Internet Draft July, 2001 authentication mechanism may directly influence the security of the underlying IPsec connection. This being the case, it seems reasonable to suggest that either the chosen mechanism should not reduce the baseline effectiveness of the underlying IPsec connection in comparison to non-remote-access connections, or (if this cannot be avoided) that the resulting security reduction should be minimized. A secondary area of concern pertains to the manner in which we might unwittingly reduce security by adding functionality which interacts with the base IPsec subsystem in unforseen ways. As systems grow in complexity, it becomes increasingly difficult to reasonably assert that such unforseen interactions are either not possible or not occurring. This is largely due to the increase in the number of system inputs and their corresponding outputs, and to our inability to accurately characterize these quantities. That is, increasing complexity makes the task of recognizing all of the possible system input/output combinations quite difficult (if not impossible) for a human mind. Hence, the probability of an oversight or error which impacts on critical system function is proportional to system complexity, and software development experience to date suggests that as systems grow increasingly complex, this probability nears unity. In response to this issue, computer-based analytical techniques have been developed to assist in the task of characterizing complex systems. These techniques seem effective in transcending the computational and organizational limitations of the human mind in many cases. However, while computer-based analytical engines might improve performance with respect to organizing and understanding complexity, these engines are ultimately designed and interpreted by the same sorts of agents as they are intended to aid, and hence may not be as accurate as hoped. Recognition of the implications of these observations is apparently difficult for some, perhaps due in part to the lack of clearcut quantifying measures for accuracy (or in this case, security) as a function of code complexity. The fact that one cannot insert the number of added lines of code into an equation to arrive at the conclusion that either a critical bug has or has not been introduced makes it difficult for some to accept the criticality of this issue when designing and implementing secure systems. Nonetheless, given the stakes in scenarios requiring high security, the implications of added complexity must not be ignored. Hence, we should strive to balance the added complexity of the chosen solution with other design goals. 3. Brief Enumeration of Proposed Solutions Kelly Expires Jan 2002 [Page 7] Internet Draft July, 2001 As noted, there are a number of proposed solutions to date. These are as follows: o XAUTH/MODECFG - XAUTH refers to eXtended AUTHentication (within IKE), and is detailed in [XAUTH]. It is tightly bound to another proposal, the ISAKMP configuration method [MODECFG]. o HYBRID - this proposal builds upon the XAUTH/MODECFG combination, adding one-sided server authentication. It is detailed in [HYBRID]. o ULA - ULA refers to User-Level Authentication; this proposal was withdrawn due to various shortcomings, but is included here for the sake of completeness. See [ULA] for additional detail. o CRACK - CRACK stands for Challenge/Response for Authenticated Cryptographic Keys, and is discussed in [CRACK]. o L2TP - L2TP (Layer 2 Tunneling Protocol) uses PPP-based authentication. Use of L2TP with IPsec is discussed in [L2TPSEC]. o PIC - PIC stands for Pre-Ike Credential provisioning protocol, and is discussed in [PIC] o GetCert - GetCert is a shorthand name for "Client Certificate and Key Retrieval for IKE", and is discussed in [GETCERT]. This document provides a (currently very) brief analysis of how each of these stacks up against the remote access user authentication requirements discussed above. 4. Common Features of Proposed Solutions Before looking at the individual proposals, it may be useful to examine some of the issues which multiple proposals have in common. A number of the proposals provide for the use of preshared keys to authenticate an IKE session prior to authenticating the user (XAUTH, ULA, L2TP), and an overlapping subset provides for the use of public key mechanisms for the same purpose. These are discussed below. 4.1 Common Issues for Proposals Supporting Preshared Keys A subset of the proposals (XAUTH/MODECFG, ULA, L2TP) provide the ability to use preshared keys as a part of the authentication process. All of these proposals, when used in this manner, share common issues, which are discussed in section 4.1.1 below. Kelly Expires Jan 2002 [Page 8] Internet Draft July, 2001 In addition, preshared keys may be used in a number of network configurations, including the following: o remote client uses fixed IP address with unique preshared key o remote client uses non-fixed IP address with global preshared key o remote client uses non-fixed IP address with unique preshared key (requires use of IKE aggressive mode) The individual issues associated with these are discussed in sections 4.1.2-4.1.4. 4.1.1 General issues for configurations using preshared keys Preshared keys, when compared to well-managed public/private key pairs, provide a significantly weaker form of authentication for IPsec. Brute force man-in-the-middle attacks on the preshared keys are possible. For example, an adversary might juxtapose himself between the remote user and the security gateway, and attempt to intercept the remote access user's connection attempt with the gateway. If the SGW can be impersonated in this manner by the attacker, the remote access client will provide the attacker with enough information so that the preshared key may be subjected to an offline dictionary attack. Once a preshared key is compromised, additional information regarding the user identity and legacy authentication passphrase is vulnerable, and if the authentication passphrase is compromised, the system has failed entirely: the attacker may impersonate the remote user. This risk may be mitigated by using one-time legacy authentication tokens, but it should be noted that the identity information will still not be protected. Further, if an attacker with MiM capability succeeds in determining the preshared key, he may then launch MiM attacks on subsequent remote access sessions in which he sits transparently in the connection path, impersonating the sgw to the remote user, and impersonating the remote user to the sgw. The implications of this are clear. These risks are not mitigated by using aggressive mode with preshared keys, which is a much more likely scenario for remote access given that the IP address of the remote access user will vary. Furthermore, the attacker need not interact with the data stream in this case, but only needs to observe the exchange. Aggressive mode proceeds as follows: Remote User Security Gateway Kelly Expires Jan 2002 [Page 9] Internet Draft July, 2001 ------------------ ---------------------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> Note that in this case, the attacker has access to the HASH_R value, along with all relevant inputs, so that a dictionary attack may again be mounted on the preshared key. Also note that in this case the SGW is forced to compute HASH_R prior to verifying the remote user's identity, implying an increased vulnerability to DoS attacks, and if the user (attacker) sends a spurious third message, the SGW must complete the DH exponentiation to detect it. In fact, methods which rely on preshared keys and aggressive mode may be trivially susceptible to DoS attacks due to this vulnerability, in that an attacker has but to construct a valid IDii payload, and this may be used again and again in order to cause the SGW to repeatedly allocate context memory, compute HASH_R, and perhaps compute the DH value. Finally, support for use of preshared keys does scale well, and does not encourage migration to stronger authentication mechanisms, and in fact, may encourage the opposite. Hence, it may be prudent from a security perspective to disallow such support in any proposed solution. Issues specific to particular uses of preshared keys for the various network configurations enumerated in section 4.1 above are discussed in the following sections. 4.1.2 Fixed Address (unique PSK) In the case where the IP address is fixed, IKE main mode may be used with a preshared key. This is an unusual situation for remote access, but it does present the ability to use a unique preshared key for each user, meaning it may be at least as secure as typical site-to- site configurations employing preshared keys. However, preshared keys within main mode are susceptible to attack as noted above, so this may provide a false sense of security. Also, use of per-user preshared keys raises obvious scalability issues as the number of users grows. 4.1.2 Non-fixed Address, Global Preshared Key In some cases, a single preshared key may be used for all remote users. A global preshared key has obvious shortcomings, and must not Kelly Expires Jan 2002 [Page 10] Internet Draft July, 2001 be recommended. Such keys may be compromised in numerous ways without detection, and once this has occurred, eavesdropping and MiM attacks are greatly simplified. This is unacceptable from a security perspective. 4.1.3 Non-fixed Address, Unique Preshared Key Unique preshared keys may be used with non-fixed addresses if IKE aggressive mode is used. However, this method is vulnerable to DoS attacks on the sgw, as the user identity is not protected, and intercepted packets may be replayed, causing the sgw to needlessly engage in hash and exponentiation calculations. This method is also susceptible to dictionary attacks on the preshared key. In addition, per-user keys do not scale as the number of users grows. 4.2 General Issues For Configurations Using Mutual Certificates In general, public key authentication mechanisms are much stronger than shared secret mechanisms. However, there are a number of issues even with these. Due to the overhead associated with authentication operations, there is some unavoidable DoS susceptibility. For example, using IKE main mode, an attacker may cause the SGW to needlessly perform expensive public key and/or Diffie-Hellman operations just to prove that the attacker is not authorized to connect. If aggressive mode is used instead of main mode, the SGW may be forced to generate its own signature without first verifying the identity of the remote user. A sufficient number of such spurious computations will impinge upon the SGW's ability to deliver services to authorized users. Note that these issues exist for site to site installations as well as remote access scenarios, although in site-to-site connections the remote IP address may be used by the SGW as an additional filter, raising the bar somewhat for the attacker. In selecting such a mechanism for remote access, we should strive to not introduce any more vulnerability than already exists in site to site scenarios. A second area of consideration pertains to the storage mechanism for the private key used to authenticate the user. If this key is compromised, the entity it authenticates may be impersonated without detection. Hence, the integrity of the derived authentication is directly proportional to the security of the private key storage technique. If the private key is stored on the hard drive of the subject system, it is vulnerable to a number of attacks, and may be compromised Kelly Expires Jan 2002 [Page 11] Internet Draft July, 2001 without detection. Therefore, the integrity of the resulting authentication in this case is directly proportional to the security of the system in which the hard drive resides. If this system is hardened, physical access is strictly controlled, and system configuration is strictly controlled, the associated level of security may be relatively high. However, if the system is (for example) a laptop containing a commercial operating system, and the user has typical freedoms regarding system usage and configuration, the associated level of security is likely quite low. In such cases, the private key may be compromised without detection in numerous ways, and even if an additional factor of authentication is used (such as a username/passphrase pair) the SGW is subject to increased vulnerability to DoS attacks (the attacker can negotiate multiple phase 1 SAs using the private key). If a post-IKE legacy user authentication mechanism is used, the underlying user authentication mechanism is also subject to attack, which may ultimately expose the protected network(s) and data. These risks may be mitigated if the private key is securely contained (e.g. in a smartcard), and if key usage requires an additional factor of authentication in advance (i,.e. stealing the key container does not necessarily guarantee access). However, it should be recognized that a sufficiently secured private key may also obviate the need for a username-passphrase exchange, unless n-factor authentication is required. So, while public key methods may seem to remedy many of the issues raised by the use of preshared keys, we must be careful to evaluate the relative security of the private keys in such scenarios. Solutions relying on insufficiently secured private keys are correspondingly insecure. 5. Comparing the Proposals 5.1 XAUTH/MODECFG Xauth is a user authentication mechanism which functions by first forming a phase 1 IKE SA using one of the conventional IKE authentication techniques (preshared key or public key), and by then extending the IKE exchange to include additional user authentication exchanges. The xauth payloads ride atop an additional proposed IKE extension (referred to as "modecfg" or "ikecfg") which is essentially a DHCP-like mechanism meant to provide host configuration parameters to remote access clients. Xauth may be deployed in at least five different configurations: Kelly Expires Jan 2002 [Page 12] Internet Draft July, 2001 o main mode using unique preshared keys (fixed IRAC address) o main mode using global preshared key (non-fixed IRAC address) o aggressive mode using unique or global preshared key and keyid o main mode using certificates o aggressive mode using certificates When used with preshared keys, xauth suffers from all of the associated shortcomings discussed above in section 4.1. When used with certificates, either the associated private keys are adequately safeguarded, or they are not. If so, xauth is superfluous, unless n- factor authentication is required. If not, the associated shortcomings are present. Specific xauth issues (in addition to the general issues discussed above) include the following: o Xauth requires the SGW to participate in the user authentication process, which increases SGW vulnerability both in terms of complexity and denial of service. o Adding an open-ended number of challenge-rsp exchanges to a key exchange increases vulnerability to denial of service attack under some circumstances, and absolutely increases the complexity of the key exchange mechanism under all circumstances. While an open-ended exchange may not be entirely avoidable given the n-factor authentication requirement, xauth does not begin such exchanges until a phase 1 IKE SA has been instantiated, and this with either limited or no knowledge of the user identity in several of the supported configurations. The overhead associated with the DH exchange is significant, and the fact that an anonymous peer may force expenditure of this effort implies that a system supporting the associated configuration is trivially susceptible to denial of service. Further, once such phase 1 sessions are established, the SGW may be "led on" by a malicious peer for some (hopefully limited) period of time, guaranteeing that the associated system resources will remain unavailable during this period. o Xauth requires proxy support in the SGW for up to 16 different authentication methods, which greatly increases system complexity. o There may be some known ascii plaintext at fixed locations within packets due to support for user prompts. The amount of text will normally be small, but should not be ignored. If a reusable passphrase is contained within the xauth exchange, an attacker may have significant motivation for breaking the IKE session encryption, and known plaintext will simplify this task. Kelly Expires Jan 2002 [Page 13] Internet Draft July, 2001 o Xauth requires support for its companion, modecfg. This duplicates some of the functionality of DHCP, but lacks support for critical components, implying that it is redundant, and therefore adds unnecessary complexity. However, one has no choice but to implement modecfg if one wishes to implement xauth. 5.2 Hybrid The "Hybrid" authentication mechanism [HYBRID] attempts to address some of the shortcomings of xauth, most notably the need to support global preshared keys when remote access client certificates are not available. The hybrid mechanism modifies the xauth mechanism by requiring the IRAS to authenticate itself using public key techniques, and deferring user authentication until after the phase 1 IKE SA is in place. That is, hybrid requires the IRAS to authenticate to the IRAC, but not vice versa - it is a one-sided authentication. This mechanism is trivially susceptible to DoS attacks, as it requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange which includes an expensive public key operation, and then to continue the conversation for some period of time beyond that, perhaps in error. In addition, all of the specific xauth shortcomings not relating specifically to preshared keys apply equally to hybrid. 5.3 ULA The previously proposed ULA method* [ULA] consists in forming an authenticated phase 1 SA in the same manner as xauth, followed by creation of a phase 2 SA whose sole purpose is to protect the authentication exchange. Following successful authentication, the phase 2 SA is either replaced, or the selectors are modified to permit access to appropriate resources. While this method improves somewhat on xauth by providing the ability to offload the user authentication to an outboard server (reachable through the tunnel), it suffers from many of the same problems as xauth. In particular, this method has the following shortcomings: o if preshared keys are used, this technique suffers from all of the general shortcoming associated with these which were identified above, e.g. vulnerability to MiM, offline dictionary attacks, undetected compromise, lack of scalability, etc. o requires IRAS to create phase 1 and phase 2 SAs without verifying user identity; this has obvious DoS implications, and is also susceptible to attacks on the underlying authentication Kelly Expires Jan 2002 [Page 14] Internet Draft July, 2001 infrastructure. These risks may be mitigated if mutual certificates are used, but as with xauth, either the user's private key is securely stored or not. If so, ULA is superfluous unless n-factor authentication is required, and if not, the associated shortcomings are present. *This proposal was withdrawn due to security issues 5.4 CRACK The CRACK technique [CRACK] integrates the user authentication process into the key exchange negotiation within IKE by defining a new exchange type. The IRAS authenticates using public key techniques, while the user authenticates using an identity and one or more passphrases. The exchange proceeds as follows: Client (I) Gateway (R) ----------- ----------- HDR, SAi, KEi, Ni [, CERTREQ] ---> <--- HDR, SAr, [CERT, ] KEr, SIG1, Nr HDR*, CHRE, PK ---> <--- HDR*, < SIG2 | CHRE > HDR*, < SIG3 | CHRE > ---> For payload definitions, see [CRACK]. This technique limits the denial of service implications for the IRAS when compared to xauth, hybrid, or ula, as the user must authenticate very early in the protocol. However, this method suffers from the following shortcomings: o IRAS must produce signature prior to authenticating user o IRAS must complete DH computation to detect spurious second message from attacker o IRAS must participate in the legacy user authentication process o requires support for an additional IKE exchange type 5.5 L2TP The L2TP user authentication mechanism is very similar to the ULA mechanism, and consists in forming both phase 1 and phase 2 SAs prior to authenticating the user. Hence, it suffers from precisely the same shortcomings as ULA (and by proxy, many of the shortcomings of xauth). However, the L2TP method also completely removes the user authentication from IPsec and moves it into PPP, so that per-user Kelly Expires Jan 2002 [Page 15] Internet Draft July, 2001 network access security must also be managed within the L2TP/PPP subsystem. This has significant implications in terms of increased system complexity. The current proposals for using L2TP with IPsec suggest using a "machine certificate" to authenticate the IKE SA. Note that as with xauth, either the user's private key is securely stored or not. If so, the L2TP user authentication may be superfluous (unless n-factor authentication is required), and if not, the associated shortcomings are present. 5.6 PIC The PIC mechanism provides a method for integrating legacy user authentication with existing IPsec deployments without the need for modifying the underlying IPsec implementations. This is accomplished by authenticating the user outside of the IPsec session proper, and providing the user with a short-lived certificate which may then be used within IKE using currently defined public key authentication mechanisms. The PIC method accomplishes user authentication using an ISAKMP exchange which supports legacy mechanisms, and then provides the user with a private/public keypair and certificate which are used for subsequent authentication operations with the security gateway. While PIC may be terminated by the target security gateway, it may also be terminated by a separate authentication server. The exchange is as follows: Client Authentication Server ------ --------------------------- (1) HDR, SA, KE, Ni --> (2) <-- HDR, SA, KE, Nr, IDir,[CERT,] SIG_R, HASH, [,...] (3) HDR*, HASH, EAP, [EAP...,] --> [CREDENTIAL-REQUEST] (4) <-- HDR*, HASH, EAP, [EAP...,] [CREDENTIAL] Security issues with this method include the following: o if PIC is run on the sgw, the sgw is subject to DoS attacks due the fact that it must generate a signature and compute a DH exponential prior to authenticating the remote access user. Kelly Expires Jan 2002 [Page 16] Internet Draft July, 2001 o separate connections are required for authentication and access; however, this implementation detail may be rendered transparent to the user 5.7 GetCert The GetCert method is a percursor to PIC, having provided the first example of the underlying model: as a result of a non-IPsec user authentication exchange, the user obtains a certificate which is used to authenticate a subsequent IKE session. The primary difference between GetCert and PIC is in the transport. While PIC runs over a new ISAKMP exchange, GetCert is completely independent of IPsec, and runs over a HTTPS/TCP connection. Security issues with this method include the following: o if GetCert is run on the IRAS, the IRAS is subject to DoS attacks due the fact that it must field incoming SSL connections from unauthenticated users o separate connections are required for authentication and access; however, this implementation detail may be rendered transparent to the user. 6. Comparison of Proposals to Requirements All of the proposed mechanisms solve the most basic problem, which is to authenticate remote access users by way of legacy authentication systems. However, they do so in several different ways. The techniques fall into 3 general categories, from a high level: o those which complete IPsec negotiation (phase 1 and/or phase 2 IKE) prior to authenticating the user (XAUTH, HYBRID, ULA, L2TP). o those which integrate the user authentication into IKE phase 1 negotiation (CRACK). o those which move the user interaction outside of IPsec entirely (PIC, GETCERT) Another way to group these is as follows: o those which require the IRAS to participate in the user authentication process (XAUTH, HYBRID, ULA, L2TP, CRACK) Kelly Expires Jan 2002 [Page 17] Internet Draft July, 2001 o those which do not require the IRAS to participate in the user authentication process (PIC, GETCERT) Recalling our goals from section 2, it is appropriate to compare the proposals against each of these at this time. 6.1 Provide direct support for legacy user authentication systems such as RADIUS All proposals meet this goal. 6.2 Encourages migration from existing low-entropy password-based systems to more secure authentication systems Proposals requiring use of public key mechanisms certainly meet this goal, while proposals supporting both preshared keys and public key mechanisms meet it to a lesser extent. PIC, GETCERT, CRACK, and HYBRID all require support for public key mechanisms. If XAUTH, ULA, and L2TP are used with preshared keys, they do not meet this goal. 6.3 If legacy support cannot be provided without some sort of migration, the impact of such migration should be minimized Since all proposals meet 6.1, this is moot. 6.4 User authentication information must be protected against eavesdropping and replay (including the user identity) Proposals requiring the use of aggressive mode do not meet this goal, meaning the preshared key modes of XAUTH, ULA, and L2TP. It might be argued that these mechanisms may use preshared keys with fixed IP addresses (and hence use main mode), but this raises obvious SGW scaling issues, and therefore these cases do not represent likely remote access scenarios. Hence, XAUTH, ULA, and L2TP only meet this goal when used with IKE main mode and public keys. All other proposals meet this goal unconditionally. 6.5 Single sign-on capability should be provided in configurations employing load-balancing and/or redundancy Only proposals which permit the user to instantiate a connection with a redundant IRAS without re-entering user authentication information Kelly Expires Jan 2002 [Page 18] Internet Draft July, 2001 (username, password, etc) meet this goal, i.e. PIC and GetCert. 6.6 N-factor authentication mechanisms should be supported All proposals meet this goal. 6.7 Security gateway vulnerability to DoS attacks should be minimized, and if possible, should not be greater than the vulnerability which exists in SGW systems not providing remote access. Proposals requiring no modification to the underlying IPsec implementation unconditionally meet this goal. The only proposals having this characteristic are PIC and GetCert, when they are run on outboard authentication servers. Proposals requiring modification to the underlying IPsec implementation must be examined more closely. All members of the class of proposals which defer user authentication until after a phase 1 SA has been negotiated (XAUTH, HYBRID, ULA, L2TP) are more vulnerable to DoS attacks than those not sharing this characteristic. CRACK, while not strictly in this class (it authenticates the user *during* phase one), must also be considered with this group due to other similarities. Of these proposals, HYBRID and CRACK are clearly the most vulnerable, since they require the SGW to perform Diffie-Hellman and public key computations for an unauthenticated peer. In the case of the other 3, the DoS implications might be minimized if main mode with (random) preshared key authentication were used for phase 1, but this is not feasible due to scaling issues. Hence, for XAUTH, ULA, and L2TP, main mode with signatures is the only realistic approach. This has a slightly higher DoS risk, but no more so than for other non-remote-access IKE exchanges using public key techniques. However, the validity of this assumption depends upon the security of the private keys used for authenticating the remote access client. As noted previously, if this key is not securely stored, DoS attacks become trivial for a determined adversary. 6.8 The chosen mechanism(s) should minimize any reduction in the baseline security of the underlying IPsec connection Proposals requiring no modification to the underlying IPsec implementation clearly meet this goal. The only proposals having this characteristic are PIC and GetCert (when implemented on outboard authentication servers). Proposals requiring modification to the Kelly Expires Jan 2002 [Page 19] Internet Draft July, 2001 underlying IPsec implementation must be examined more closely. All proposals other than PIC and GetCert modify the underlying IPsec implementation, and so introduce some probability that the security of the underlying implementation (and therefore, that of the connection) has been reduced. The XAUTH, HYBRID, and CRACK approaches all directly modify IKE by adding new states and protocol elements. This certainly increases code complexity, along with the probability of an implementation error. However, this effect is most difficult to quantify. In addition, all approaches other than PIC and GetCert (and perhaps L2TP) require the SGW to act as a proxy in the user authentication protocol. L2TP may avoid this by terminating the L2TP tunnel on a host behind the SGW rather than on the SGW itself, but if this is done, then there must also be some protocol between the L2TP termination point and the SGW which permits access revocation if the user fails to properly authenticate - otherwise, the L2TP server may terminate the connection, but the SGW won't know it - which again adds complexity to the SGW. 7. Summary The various proposals come out on fairly equal footing regarding several of the stated requirements, with differences emerging in the following 3 areas: o increased SGW susceptibility to DoS attacks o increased SGW complexity o single sign-on support These are discussed in more detail below. 7.1 DoS Susceptibility XAUTH, HYBRID, ULA, CRACK, and L2TP are all susceptible to DoS attacks under some circumstances. HYBRID and CRACK are trivially susceptible to DoS attacks. PIC and GetCert only increase the SGW's DoS susceptibility if they are implemented on the SGW. L2TP, ULA, and XAUTH are less susceptible than HYBRID and CRACK if the remote user's private key is securely contained, but only in this case. To the extent that the private key is susceptible to compromise, the DoS risk increases proportionally. As noted earlier, a private key stored on the hard drive of a typical user system would not stand up to a determined adversary. Kelly Expires Jan 2002 [Page 20] Internet Draft July, 2001 While it may be argued that using a smartcard (or other secure container) goes a long way toward resolving this problem, it must be noted that this imposes a significant increase in the cost of the solution, both economically and logistically. In this case, smartcards (or whatever security container is used) must be provided for each remote access user, and these must be managed. And if one is stolen, it may be used for DoS attacks (or worse, unfettered access) until it is discovered missing. An alternative to secure containers is to provide a short-lived key at the time access is desired which is good for a limited time only. The short lifetime of the key significantly narrows the window during which it might be compromised, and if such a key were somehow compromised, the damage potential would be bounded by its lifetime. That is, if the key lifetime is sufficiently short, the only realistic compromise scenario (for DoS purposes) entails gaining control of the system while the key is valid and passing it along to the attacker. However, an attacker with this capability can also gain control of a system relying on a smartcard, and by proxy, full access to the network beyond the SGW - so the smartcard is not much help in this case, and in such a case, DoS attacks should be the least of our concerns. 7.2 Code Complexity XAUTH, HYBRID, ULA, CRACK, and L2TP all significantly increase the complexity of the IRAS code base, while PIC and GetCert need not be implemented on the IRAS. 7.3 Single Sign-on Support XAUTH, HYBRID, ULA, CRACK, and L2TP do not provide for single sign-on support, while GetCert and PIC do (the short-lived certificate may be used to connect to a redundant IRAS). 7.4 Conclusion The only proposals which meet all criteria are GetCert and PIC (when implemented on an outboard authentication server). 8. Security Considerations The topic of this document is secure remote access. Security Kelly Expires Jan 2002 [Page 21] Internet Draft July, 2001 considerations are discussed throughout the document. 9. Editors' Addresses Scott Kelly RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: skelly@redcreek.com Telephone: +1 (510) 745-3969 10. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [KR01] S. Kelly, S.Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", draft-ietf-ipsra-reqmts-03.txt (work in progress). [XAUTH] Pereira and Beaulieu, "Extended Authentication within ISAKMP/Oakley XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress). [MODECFG] R Pereira, S. Anand, B. Patel, "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-mode-cfg-05.txt (work in progress) [ULA] S. Kelly, J. Knowles, B. Aboba, "User-level Authentication Mechanisms for IPsec", draft-kelly-ipsra-userauth-00.txt, (work in progress) [CRACK] D Harkins, B Korver, D Piper, "IKE Challenge/Response for Authenticated Cryptographic Keys", draft-harkins-ipsec-ike- crack-00.txt (work in progress). [L2TPSEC] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing L2TP using IPSEC", draft-ietf-l2tpext-security-02.txt" (work in progress) [PIC] Y. Sheffer, H. Krawczyk, "PIC, A Pre-IKE Credential Provisioning Protocol ", draft-ietf-ipsra-pic-01.txt, (work in progress) Kelly Expires Jan 2002 [Page 22] Internet Draft July, 2001 [GETCERT] Bellovin and Moskowitz, "Client Certificate and Key Retrieval for IKE", draft-bellovin-ipsra-getcert-00.txt (work in progress). 11. Full Copyright Statement Copyright (C) The Internet Society (1998). 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. Kelly Expires Jan 2002 [Page 23]