Network Working Group Scott Kelly, Jim Knowles INTERNET-DRAFT RedCreek Communications draft-kelly-ipsra-userauth-00.txt Bernard Aboba, Microsoft Expires in 6 months October, 1999 User-level Authentication Mechanisms for IPsec 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 its 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Comments on this document should be sent to "ietf-ipsra@vpnc.org", the IPsec remote access discussion list. Abstract IPsec, when used with IKE [RFC2409], provides for authentication of endpoints from the device level to the user level. However, there has been movement within the IPsec development community to provide additional support for legacy user-level authentication mechanisms such as those supported by RADIUS [RFC2138]. At least 2 approaches to this problem have been proposed thus far, both using the same basic underlying framework, but that underlying framework relies upon extending IKE in ways that may not be prudent. This document proposes an alternative approach which provides much of the same functionality without requiring any modification to the existing IPsec framework. Kelly, Knowles, Aboba Expires April, 2000 [Page 1]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 1. Introduction IPsec, when used with IKE [RFC2409], provides for strong authentication of endpoints from the device level to the user level. The authentication methods supported range from preshared secrets to X.509 certificates. The entity authenticated by these mechanisms may be only the device, especially in cases where no user input is required in order for the subject device to access the IKE authentication credential. However, varying levels of user input may be required to provide the device with access to the authentication credential, in which case a single-factor or two-factor authentication mechanism may be employed. An example of a single-factor authentication mechanism which provides relatively weak user-level authentication would be one in which the user provides a password which is then used as a preshared key for IKE authentication. A second example, perhaps slightly stronger, might consist in the user plugging in a smartcard which contains the authentication material (and perhaps applies it using an embedded processor), but which does not require the user to somehow "unlock" it. An example of strong two-factor authentication in this context might be realized if the user were required to first plug in a smart card containing the user's identity certificate, and then unlock that card using a non-trivial challenge/response mechanism. Even this mechanism has its limitations, depending upon one's level of paranoia, but these limitations are not due to any shortcoming in IPsec per se; rather, they are inherent in the nature of computer security. While numerous authentication mechanisms (including some very strong ones) are currently supported by IPsec, there has been movement within the IPsec development community to provide additional support for legacy authentication mechanisms such as those supported with RADIUS [RFC2138] and GSS_API [GSS]. RADIUS-supported mechanisms include authentication methods supported in PPP [RFC1661], including PAP, CHAP, and EAP [RFC2284]. Such support is generally viewed as a necessary stepping stone to broad support for public key mechanisms. The movement for legacy support has been especially concerned with deployments supporting remote access, wherein users typically access the resources of a corporate network from a remote location. In many of these cases, other remote access mechanisms such as those discussed above have been in use prior to the IPsec deployment, and in such cases, the administrators of these deployments often wish to continue using installed authentication and accounting mechanisms in order to preserve their investment in these technologies and lessen administrative costs. Kelly, Knowles, Aboba Expires April, 2000 [Page 2]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 At least 2 approaches to this problem have been proposed [XAUTH, HYBRID], both using the same basic underlying framework, but differing in otherwise substantial ways. However, the underlying framework detailed in [XAUTH] relies upon extending IKE in ways that may not be prudent. This document proposes an alternative approach which provides much of the same functionality without requiring any extension to the existing IPsec framework. 1.1 Reader Prerequisites Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to understanding the concepts discussed here. Familiarity with RADIUS, L2TP, and PPP [RFC1661] will also be helpful, though not strictly necessary. 1.2 Requirements Keywords The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. 2. User-level Authentication 2.1 General considerations In general, the motivation for extended authentication methods arises from the network administrator's desire to authenticate the remote user in a meaningful manner prior to providing access to valued resources. While such functionality may ultimately be provided by a reliable Public Key Infrastructure (PKI), such a PKI is not yet widely deployed. As a result, many administrators providing remote access desire IPsec support for the authentication and accounting mechanisms which they currently utilize with other remote access mechanisms. In addition to the lack of ubiquitous PKI, there is other motivation for continued support of existing mechanisms. While we might imagine a future in which all computer users carry a hardware mechanism such as a smart card, and in which all computer systems have peripheral hardware capable of utilizing such mechanisms, this day may never arrive. Regardless, cases will exist in which PK certificates are somehow stored upon the system from which they are used. While these certificates may be password (or otherwise) protected, there is always the possibility that either the certificate access mechanism has been compromised, or that the current session user is not the Kelly, Knowles, Aboba Expires April, 2000 [Page 3]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 user who initially provided access to the certificate. In these cases, the end user is not authenticated; rather, the machine itself has been authenticated. As a matter of clarification, it is important to make a distinction between authenticating a device and authenticating a user. In cases where no user interaction is required in order for a device to form an IKE security association with another system, it is clearly the device which has been authenticated, and not the user. In cases where user input is required which influences the authentication credential selection or production process, some degree of user-level authentication results. However, as noted above, this degree of authentication may be dependent upon other factors, and may vary with time. Given the varying levels of user authentication which are achievable using PKI mechanisms, it will likely remain desirable to continue to provide support for existing and new User-Level Authentication (ULA) techniques which may be used in conjunction with PKI mechanisms. In general, existing ULA techniques are based on one of 2 mechanisms: static pass phrases, or dynamic tokens. Dynamic tokens may be time- dependent, or may be formulated as a response to a challenge of some sort, while static pass phrases are generally text strings of some sort which are associated with a given identity. Static pass phrases are usually a very weak form of authentication. On the other hand, they will likely remain popular due to their convenience. It seems clear that the ideal solution to the ULA problem entails an approach which supports existing ULA mechanisms while paving the way for PKI deployment, since such mechanisms will likely continue to be required even after a PKI is deployed. Therefore, our goal should be to provide an integration strategy which couples these mechanisms in the most secure manner. Such a strategy necessarily entails a PKI transition. This is discussed in the next session. 2.2 The PKI Transition The need for integration of a PKI transition strategy with the deployment of other ULA mechanisms is evidenced by the movement toward providing ULA mechanisms within IKE as a response to remote access requirements. In general, some sort of PKI is a hard requirement for widespread deployment of secure remote access solutions, since the security of preshared keys is highly dubious in this context. The issues associated with such a PKI transition are discussed below. The transition to a PKI may be divided into several steps: Kelly, Knowles, Aboba Expires April, 2000 [Page 4]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 a. Support for PKI on VPN servers. This typically requires that machine certificates be deployed on the servers, along with appropriate certificate authorities and stores. It also requires that clients be capable of verifying the server's certificate against a current Certificate Revocation List (CRL). Since this will often require a client software upgrade, the work to transition to server certificates is comparable to the work required to deploy SSL/TLS-capable Web server and certificate- capable browsers. Note that while client software support for PKI must be assumed, in this step, it is not necessary for the clients to obtain their own machine or user certificates. Thus it is possible for the clients to continue to authenticate using only legacy methods during this phase of the transition. b. Support for machine certificates on VPN clients. This requires that machine certificates be deployed on VPN clients. Completion of the previous step (a) often requires a client upgrade, which will typically also include support for client certificates. If the infrastructure for machine auto-enrollment has also been put in place as part of the server PKI rollout, then there may not be much additional work required to complete this step, above what was already required for the previous step. Note that if the VPN client only supports a machine certificate, then this may imply the use of a non-PKI method for user authentication in addition to the machine certificate. c. Support for user certificates. This requires that user certificates be provided to users. Since storage of user certificates on the machine creates new vulnerabilities, smartcards may typically be used to store the user certificates. Thus, a smartcard rollout may often be a prerequisite to deployment of user certificates. This in turn may require integration of smartcard provisioning with the existing identification system, such as the distribution of combined employee badge/smartcards. Since this step may require considerable work above and beyond the tasks required to carry out transition steps a and b, support for legacy authentication methods will likely be required at least until this transition step is complete. 2.3 Previously Proposed Solutions There have been at least two mechanisms proposed as solutions for the ULA problem thus far, and these are discussed in [XAUTH] and [HYBRID]. While these documents do not explicitly acknowledge the Kelly, Knowles, Aboba Expires April, 2000 [Page 5]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 need for a PKI transition, they rely heavily upon it. [XAUTH] relies upon it because it requires a reliable authentication mechanism for the communicating systems (i.e. PK certificates) in order to be meaningful in a security context, and [HYBRID] relies upon it due both to its incorporation of PK certificates on the server side (and verification on the client side), and to its reliance on [XAUTH] as an underlying framework. These are discussed individually below, followed by a discussion of an alternative mechanism. 2.4 Extended Authentication within IKE (xauth) The xauth mechanism [XAUTH] utilizes an existing phase 1 IKE Security Association (SA) to protect a secondary authentication exchange within IKE prior to negotiation of an IPsec protocol SA. This is often referred to as "phase 1.5" due to its juxtaposition between IKE phases 1 and 2. This mechanism currently relies upon another proposed IKE protocol extension mechanism [ISACFG], and both substantially modify the existing IKE protocol. The following diagram clarifies the relationships of the various components: +------------------+ +---------+ | security gateway | +--------+ | radius |------| +---------------+| IKE SA | remote | | server | | | co-resident ||<=========>| client | | |<======>|authentication || | | +---------+ | | proxy appl. || +--------+ | +---------------+| +------------------+ Issues with xauth include the following: o susceptible to man-in-the-middle attack if preshared key is used for IKE authentication, and so requires both server and client PK certificates for most deployments. o depends upon yet another framework for its basis [ISACFG] o adds significant complexity to the key exchange protocol, not only by adding an open-ended number of challenge- response exhanges, but by providing proxy support for 16 different legacy authentication mechanisms. The resultant implementation complexity introduces significant security risks. Kelly, Knowles, Aboba Expires April, 2000 [Page 6]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 o there is substantial known plaintext in the encrypted exchanges. These are serious issues, and should disqualify this proposal from serious consideration as a security protocol extension. To clarify, each of these issues is discussed individually below. Man-in-the-middle attacks The vulnerability to man-in-the-middle attacks occurs because in preshared key authentication in main mode, it is necessary for keys to be computed prior to the receipt of the identification payload. Therefore the selection of the preshared key may only be based on information contained in the IP header. However, in remote access situations, dynamic IP address assignment is the rule, so that it is typically not possible to map an IP address to a user identity and a preshared key. Thus the preshared key can no longer function as an effective shared secret; the same preshared key must be shared by a group of users. In this situation, neither the client nor the server individually authenticates itself during IKE phase 1; it is only known that both parties are a member of a group with access to the shared secret. This permits anyone with access to the group secret to act as a man-in-the-middle. Hence, [XAUTH] requires both server and client certificates in most cases. Note that this vulnerability does not occur in aggressive mode since the identity payload is sent earlier in the exchange. Of course, when aggressive mode is used the user identity is exposed and this may be undesirable. In fact, aggressive mode raises other security concerns, but these are not discussed here. Dependency on [ISACFG] [XAUTH] requires support for the additional proposed configuration mechanism described in [ISACFG]. This presupposes that this configuration framework is appropriate in its own right, but this has not been demonstrated. Binding [XAUTH] to [ISACFG] increases the difficulty associated with complexity analysis, and requires that the two proposals advance together. Complexity Issues The approach described in [XAUTH] significantly complicates IKE by adding a new exchange type, by extending the negotiation process in an open-ended fashion, by binding itself to yet another IKE extension, and by adding text-string processing requirements. While either of the first two issues taken alone might not be cause for much alarm, the aggregation of these, along with the others, Kelly, Knowles, Aboba Expires April, 2000 [Page 7]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 render this mechanism significantly more complex than the base IKE exchange, and much more prone to error. Given the critical nature of the key exchange with respect to the resulting session security, it is imprudent to unnecessarily introduce complexity to this protocol component. Known Plaintext There is a significant amount of known plaintext in the exchanges described in [XAUTH]. Below is an example exchange. Note that the text given here in upper case is precisely what is encrypted and sent over the wire (for the given authentication type), as documented in [XAUTH]: IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="") REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar") --> <-- REQUEST(TYPE=GENERIC MESSAGE="Enter your password followed by your pin number" NAME="" PASSWORD="") REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") --> <-- SET(STATUS=OK) Without question, there is a significant amount of known plaintext here. An adversary could passively collect any number of these exchanges, and then analyze them at leisure. Note that it is not necessary to break the session in real time in order to compromise a password and subsequently gain access to the remote network. However, real time attacks are a possibility in sufficiently long- lived sessions. It must be emphasized that it is not the general functionality that [XAUTH] strives for which is in question here, though the advisability of providing proxy protocol support for 16 different legacy authentication mechanisms is certainly questionable. Rather, Kelly, Knowles, Aboba Expires April, 2000 [Page 8]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 it is the insertion of this mechanism into the key exchange protocol, and the general manner in which it is constructed, which should be recognized as imprudent. Note that the support for such a large number of legacy methods appears unnecessary, given that most of the mechanisms are already supported within existing IETF standards-track frameworks such as GSS_API [GSS], SASL [SASL] and EAP [RFC2284]. Thus, the introduction of yet another user authentication framework is highly inefficient. By leveraging existing frameworks it would be possible to simultaneously provide wider legacy support while dramatically decreasing the code and complexity required to provide this functionality. 2.5 A Hybrid Authentication Mode for IKE The hybrid authentication method [HYBRID] uses [XAUTH] as a framework upon which to build. Hence, it suffers from many of the deficiencies of [XAUTH], namely excessive key exchange protocol complexity, dependency on [ISACFG], and substantial known plaintext in the exchanges. However, the hybrid mechanism resolves the man-in-the- middle susceptibility by requiring the security gateway to authenticate using a certificate, while permitting the user to be authenticated based upon some challenge-response mechanism. By only requiring a server certificate, Hybrid authentication provides more transition benefits than [XAUTH], which can only be safely deployed with both server and client machine certificates. However, as noted earlier, once full server certificate support is put in place, there may not be that much extra work involved in supporting client machine certificates. Thus the hybrid approach may provide only limited transition benefits above what is already supported in IKE. If [HYBRID] were made independent of [XAUTH], it would be substantially enhanced. However, there would still be questions as to its necessity and utility. For [HYBRID] to provide meaningful security, the client must be able to validate the security gateway's certificate, or else session is susceptible to a man-in-the-middle attack. That is, this functionality relies upon the presence of a PKI infrastructure for its security. So, [HYBRID] requires a meaningful PKI capability in both the client and the server, yet it stops short of simply taking one more step and enrolling the client for a certificate of its own. If the client had its own certificate, the need for the hybrid framework would disappear entirely. On the other hand, and especially in view of the desire for legacy- Kelly, Knowles, Aboba Expires April, 2000 [Page 9]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 to-PKI transition mechanisms, there may yet be some limited usefulness for the hybrid approach, especially if it is freed from dependence upon xauth. The authors of [HYBRID] are invited to consider how its general principles might be integrated into the framework presented below. 2.6 Reasonable design goals Before proceeding to propose a solution to the various problems associated with ULA in the IPsec context, we should first assert some design goals. These might include the following: o Provide support for existing legacy components, and make it transparent inasmuch as this is possible o Permit a transition to Public Key infrastructure beginning at step a in the transition process, support for server certificates. o Use the existing IPsec framework without modification if possible o Use existing standardized authentication framework(s) o Provide mechanisms which ultimately encourage migration toward newer, stronger authentication technologies, but which do not force such migration. Regardless, do not permit a failure to migrate to more appropriate techno- logies by some administrators to precipitate the weaken- ing of security protocols as an IETF response. 3. An Alternative to Xauth and Hybrid 3.1 Overview It is not difficult to arrive at an alternative to xauth/hybrid which does not suffer from many of the associated shortcomings, given the design goals enumerated above. Supporting existing legacy systems requires either that the client or the security gateway (sgw) speak with the legacy authentication server. If this is to be password based, it makes sense that the sgw implements a proxy server so that it is privy to the results of the exchange, and this is also supported by the desire to use an existing standardized authentication protocol. Also, if we are to use the existing Ipsec framework, we must somehow use the policy database on the sgw to control access. And if we are to encourage migration, we should strive to encourage the use of a PKI in place of or in addition to transmitted passwords or tokens. Given these considerations, a fairly Kelly, Knowles, Aboba Expires April, 2000 [Page 10]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 straightforward scheme emerges, detailed below: o the security gateway implements a co-resident authentication proxy application which uses a standard authentication protocol. o the client establishes a securely authenticated IKE SA followed by an IPsec SA with selectors which indicate the authentication proxy application on the gateway. o the client interacts with the authentication proxy, providing a password, token or whatever is required. o if the client successfully authenticates, the authentication proxy adds selectors to the Security Policy Database (SPD) which permit access to the corporate network. These selectors MAY point to the same phase 2 SA as was used for authentication, or MAY require the instantiation of new phase 2 SA. In the case of a new phase 2 SA, the original selectors permitting access to the proxy application MAY remain as well, allowing for later re-authentication if needed. This selector addition results in a temporary selector entry in the same manner as name selectors described in [RFC2401, p19]. o If the client fails to authenticate after a (small) predetermined number of attempts, the client MUST be locked out. Failure to authenticate is an auditable event. This mechanism is much simpler than those previously proposed, in that it relies almost entirely upon the existing framework, and requires no modifications to existing IPsec protocols. Compliant IPsec implementations should already support the addition of temporary policy selectors, and existing xauth/hybrid implementations already must support a co-resident authentication proxy. 3.2 The ULA Protocol Of fundamental importance to the simplicity of the above described mechanism is the authentication proxy, and the protocol(s) it supports. Other proposed mechanisms advocate support for numerous individual mechanisms, leading to unacceptable implementation complexity. This problem has been addressed within existing IETF authentication frameworks such as EAP [RFC2284], GSS_API [GSS], and SASL [SASL]. Kelly, Knowles, Aboba Expires April, 2000 [Page 11]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 Note that while these frameworks provide differing degrees of integrity protection taken on their own, when carried out under the protection of an IPSEC SA based on a fully authenticated IKE SA, they would inherit the authentication, integrity and replay protection services of IPSEC. This would be effectively realized by encapsulation of relevant authentication protocol exchanges within an IP transport protocol. Note that while GSS_API and EAP can be encapsulated within UDP, SASL support assumes TCP transport. Thus an additional port would be needed to serve as a UDP/TCP endpoint. 4. Shortcomings and Strengths compared to other mechanisms 4.1 Shortcomings o this approach is somewhat susceptible to Denial of Service (DoS) attacks, due to the amount of processing necessary to generate both IKE and IPsec protocol Sas. However, such an attack requires that the phase 1 credential be compromised, and may be mitigated by lockout after some number of failures. o There may be known plaintext in the authentication exchange. This may be mitigated by random ordering of TLV payloads within the exchange, and in any event, this mechanism provides far less known plaintext than xauth or hybrid. 4.2 Strengths o no modifications to existing IPsec protocols o significantly reduces implementation complexity o provides clear migration path to PKI-based mechanisms o utilizes standardized authentication protocols 5. Security Considerations This document describes a mechanism for providing various degrees of user-level authentication prior to allowing general access via an IPsec protocol SA. It is assumed that the IKE (phase 1) SA is authenticated in a meaningful manner prior to engaging in user-level authentication. If preshared keys are used for such authentication, extreme care must be exercised in distributing and storing these Kelly, Knowles, Aboba Expires April, 2000 [Page 12]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 keys, since compromise of the preshared key results in susceptibility to a man-in-the-middle attack. In cases where compromise could result in significant loss, preshared keys SHOULD NOT be used. It must be emphasized that this mechanism adds nothing to the security of the underlying IKE/IPsec SAs, but simply serves instead to authenticate a user whose data is to be transported within the associated protocol SA. 6. Authors' Addresses Scott Kelly RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: skelly@redcreek.com Telephone: +1 (510) 745-3969 Jim Knowles RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: jknowles@redcreek.com Telephone: +1 (510) 745-3977 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA email: bernarda@microsoft.com Telephone: +1 (425) 936-6605 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 Kelly, Knowles, Aboba Expires April, 2000 [Page 13]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 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. 7. References [GSS] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. [HYBRID] M. Litvin, R. Shamir, and T. Zegman, "A Hybrid Authentication Mode for IKE", June 1999, draft-ietf-ipsec-isakmp-hybrid-auth-02.txt [ISACFG] R. Pereira, "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-cfg-03, (expired) [RADIUSEXT] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft-ietf-radius-ext-04.txt, Internet Draft (work in progress), May 1999. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, RFC 1661, July 1994. [RFC2138] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138 [RFC2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. Kelly, Knowles, Aboba Expires April, 2000 [Page 14]
Internet Draft draft-kelly-ipsra-userauth-00.txt October, 1999 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999. [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication Within ISAKMP/Oakley", September 1999, draft-ietf-ipsec-isakmp-xauth-05.txt Kelly, Knowles, Aboba Expires April, 2000 [Page 15]