IPsec Remote Access Working Group                  Scott Kelly, RedCreek
INTERNET-DRAFT                                 Sankar Ramamoorthi, Nexsi
draft-ietf-ipsra-reqmts-03.txt                             January, 2001


             Requirements for IPsec Remote Access Scenarios


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

   IPsec offers much promise for securing remote access. However, there
   are a number of differing remote access scenarios, each having some
   shared and some unique requirements. A thorough understanding of
   these requirements is necessary in order to effectively evaluate the
   suitability of a specific set of mechanisms for any particular remote
   access scenario. This document enumerates the requirements for a
   number of common remote access scenarios.










Kelly, Ramamoorthi          Expires July 2001                  [Page 1]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


                             Table of Contents

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
1.4 Document Organization  . . . . . . . . . . . . . . . . . . . . .   9
2. Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
2.1 Endpoint Authentication  . . . . . . . . . . . . . . . . . . . .  10
2.1.1 Machine-Level Authentication . . . . . . . . . . . . . . . . .  10
2.1.2 User-Level Authentication  . . . . . . . . . . . . . . . . . .  11
2.1.3 Combined User/Machine Authentication . . . . . . . . . . . . .  11
2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . .  12
2.1.5 Compatibility With Legacy Mechanisms . . . . . . . . . . . . .  13
2.2 Remote Host Configuration  . . . . . . . . . . . . . . . . . . .  14
2.3 Security Policy Configuration  . . . . . . . . . . . . . . . . .  15
2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . . . . .  17
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
3.1 Telecommuters (Dialup/DSL/Cablemodem)  . . . . . . . . . . . . .  18
3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . .  19
3.1.2 Device Configuration Requirements  . . . . . . . . . . . . . .  20
3.1.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  21
3.1.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  22
3.1.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  22
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . .  23
3.2.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  23
3.2.2 Device Configuration Requirements  . . . . . . . . . . . . . .  24
3.2.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  25
3.2.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  25
3.2.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  25
3.3 Extranet Laptop to Home Corporate Net  . . . . . . . . . . . . .  26
3.3.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  26
3.3.2 Device Configuration Requirements  . . . . . . . . . . . . . .  27
3.3.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  27
3.3.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  28
3.3.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  28
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . .  29
3.4.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  29
3.4.2 Device Configuration Requirements  . . . . . . . . . . . . . .  30
3.4.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  30
3.4.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  30
3.4.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  30
3.5 Remote Dialup Laptop (Road Warrior) Access . . . . . . . . . . .  31
3.6 Third Party System to Target Network . . . . . . . . . . . . . .  31
3.6.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  31
3.6.2 Device Configuration Requirements  . . . . . . . . . . . . . .  33
3.6.3 Policy  Configuration Requirements . . . . . . . . . . . . . .  33
3.6.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  33
3.6.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  33




Kelly, Ramamoorthi          Expires July 2001                  [Page 2]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


                        Table of Contents, cont.

4. Scenario Commonalities  . . . . . . . . . . . . . . . . . . . . .  33
5. Security Considerations . . . . . . . . . . . . . . . . . . . . .  34
6. Editors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34
7. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  34
8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  35
9. Full Copyright Statement  . . . . . . . . . . . . . . . . . . . .  35
Appendix A: Change Log . . . . . . . . . . . . . . . . . . . . . . .  36









































Kelly, Ramamoorthi          Expires July 2001                  [Page 3]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


1. Introduction

   Until recently, remote access has typically been characterized by
   dial-up users accessing the target network via the Public Switched
   Telephone Network (PSTN), with the dial-up connection terminating at
   a Network Access Server (NAS) within the corporate domain. The
   protocols facilitating this have usually been PPP-based, and access
   control, authorization, and accounting functions have typically been
   provided using one or more of a number of available mechanisms,
   including RADIUS [RADIUS]. Note that for such access, it has been
   assumed that the communications infrastructure supporting the
   connection (the PSTN) is relatively secure, and poses no threats to
   communications integrity or confidentiality.

   Such connections, while economical when the communicating parties are
   within the same local exchange, become costly if the intervening
   distance between parties requires a toll call. In response to this,
   PPP-based tunneling mechanisms [L2TP, PPTP] have been developed to
   provide remote access by allowing the user to first dial into a local
   ISP account, and then tunnel an additional PPP connection over the
   Internet into the target network. The developers of these mechanisms
   have long recognized that vulnerabilities arise when data travels
   over the public Internet, and have awaited the deployment of IPsec as
   a response to these vulnerabilities.

   Of the various tunneling mechanisms, the market seems to be settling
   down around L2TP, but there are a number of pertinent issues with
   respect to transit security within L2TP. In brief summary, these
   include the following:

     o weak tunnel endpoint authentication (shared secret only)
     o no data stream integrity mechanism
     o reliance upon PPP for encryption service

   With respect to the first item above, while a certain level of tunnel
   endpoint authentication is provided during L2TP tunnel establishment
   (using a shared secret),  it is possible for an observer to inject
   traffic into the L2TP tunnel stream once this authentication step is
   complete.  It is also possible to modify the datastream, or to hijack
   the tunnel.  These are consequences of both the first and second
   issues listed.  Confidentiality also poses a significant challenge
   for such tunneling mechanisms.  Prior to IPsec deployment, L2TP has
   been made to rely upon the encryption service provided by PPP. This
   service is inadequate for many applications from a security
   perspective, due in part to its reliance on manual configuration of
   encryption keys, and also to the lack of a data stream integrity
   mechanism during selection of the encryption protocol and keys.




Kelly, Ramamoorthi          Expires July 2001                  [Page 4]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   It has been believed that IPsec would resolve these issues, given its
   support for dynamic authenticated key exchange, data stream integrity
   verification, and confidentiality. Indeed, the increasing
   availability of IPsec renders it possible to provide more secure
   remote access to resources via the Internet than has been available
   in the past. Given this, and the fact that L2TP and related protocols
   have been refined over the years to meet the needs of the remote
   access community, it seems appropriate to ask if L2TP combined with
   IPsec would provide an acceptable and even highly desirable solution
   to the problem of secure remote access. The answer is that while
   combining L2TP and IPsec may be a sufficient solution for some remote
   acess deployments, it is not a universal remote access solution, due
   to a number of inherent security issues.

   When combining IPsec and L2TP, a number of security issues must be
   addressed.  These points are summarized in the following list, and
   then discussed in further detail below:

     o the transit selectors become opaque to the IPsec implementation,
       meaning tunnel membership must be enforced within the L2TP
       implementation

     o user-level authentication does not occur until an IPsec SA has
       been established

     o the most common user-level authentication mechanism employed
       within L2TP (RADIUS), has known security issues

     o the increased complexity resulting from combining L2TP/IPsec
       implementations significantly increases the likelihood of
       introducing a security-compromising bug

   The first issue pertains to where tunnel membership is enforced.
   IPsec is designed to provide tunnel membership enforcement with
   regard to transit traffic. However, when combining L2TP and IPsec,
   the only transit selectors visible to the IPsec implementation are
   the outer IP and encapsulating  UDP headers. Hence, the L2TP
   implementation must enforce tunnel membership, ensuring that packets
   emerging from a given L2TP tunnel have the appropriate source and
   destination addresses in accordance with the instantiated security
   policy.

   The second L2TP/IPsec issue pertains to the manner in which user
   authentication is accomplished. That is, the secure (IPsec) channel
   must be established first, with user authentication following within
   L2TP. This means that the security gateway terminating the remote
   access connection must either accept some weak form of authentication
   (e.g. a universal preshared key), or use public-key-based



Kelly, Ramamoorthi          Expires July 2001                  [Page 5]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   authentication. If a universal preshared key is used, this has
   obvious security implications, as such a key may be compromised in
   numerous ways. In such cases, the SGW can be made to expend a great
   deal of resources engaging in spurious key exchange calculations, or
   perhaps worse, a compromised key may be used to open a conduit to the
   underlying user authentication mechanism, through which other attacks
   may be launched.

   The best way to mitigate these vulnerabilities is to use reliable
   PKI-based mechanisms to authenticate the initial connection. This
   requires that a private key (with a corresponding public key
   certificate) be made available to the user's system, and that the
   user's system be capable of verifying a public key certificate
   presented by the security gateway granting access to the target
   network. Some have suggested providing a relatively long-lived
   certificate which binds a keypair to a particular system (rather than
   a user), and using this to authenticate the initial connection. This
   is effective if and only if the private key is adequately secured
   during distribution, storage and use, and this is very difficult to
   achieve given the open nature of commonly-used commercial operating
   systems.  It is likely not achievable unless the private key is
   stored and used within a secure container of some sort (e.g. a
   tamper-resistant smartcard), this container cannot be easily moved to
   another system, and the system cannot easily be appropriated and used
   by someone without authorization.

   If such a secure containment mechanism cannot be provided, (e.g. a
   private key is instead stored on the local hard drive and this is
   used to authenticate the system), then additional security issues
   certainly exist. Such keys may be compromised in numerous ways, and
   such compromises may go undetected indefinitely. Similar issues exist
   if the system is vulnerable to either theft or unauthorized use. In
   all cases, the end result is very similar to that of the universal
   preshared key, in that once an attacker has a valid private key,
   attacks upon the underlying user authentication mechanism are
   possible, as well as DoS attacks. Hence, to mitigate the associated
   risks, such keys must be relatively short-lived. This implies a need
   for a secure mechanism for periodically refreshing such credentials,
   with the associated refresh interval being adjustable according to
   the desired level of assurance.

   Assuming we choose to use L2TP/IPsec, that the user's system is
   protected from theft and unauthorized use, and that an acceptably
   secure PKI-based authentication mechanism is employed for creating
   the IPsec channel which does not include user-level authentication, a
   second security issue arises. The user is now expected to
   authenticate by providing a username and password. In most current
   deployments, the L2TP tunnel termination point must provide this



Kelly, Ramamoorthi          Expires July 2001                  [Page 6]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   information to a RADIUS server, and permit or deny access based upon
   the server's response.  If the RADIUS server does not co-reside with
   the L2TP implementation, there are a number of well-known security
   issues with the ensuing online RADIUS conversation.  If the target
   network upon which this RADIUS conversation occurs is not completely
   trusted, and the conversation between the SGW and the RADIUS server
   is not secured (e.g. using IPsec), then it is possible that the
   username and password may be compromised. Note that this must be
   considered regardless of whether L2TP is used, if legacy mechanisms
   such as RADIUS require support.

   Note that if the username and password are used prior to tunnel
   establishment in order to obtain a short-lived public key
   certificate, the L2TP authentication mechanism becomes somewhat
   superfluous. On the other hand, if the user identity is not bound to
   the IPsec authentication credential, and the credential is not stored
   in a theft and tamper resistant container within which it is used,
   numerous attacks become possible. While such risks may be acceptable
   for some installations, they will not be in others. As always,
   mechanisms which provide for a gradation of assurance levels
   according to need are most useful, and derivation of such mechanisms
   should be the aim of a secure remote access design effort.

   The third issue in combining L2TP and IPsec listed above relates to
   the increased complexity resulting both from adding the additional
   L2TP layer, and from the resulting interactions between the layers.
   This is by far the most difficult of the three issues to quantify,
   though current experience with such systems indicates that the number
   of software bugs which are not identified in the test phase increases
   with code complexity. Hence, if the security requirements of a given
   remote access scenario call for a high assurance system, this
   interaction must be taken into account in selecting the remote access
   mechanism.

   Remote access via the Internet has numerous benefits, financial and
   otherwise. However, security is paramount, and this presents strong
   incentives for migration from the old dial-up model to a more secure
   IPsec-based remote access model. Meeting the security requirements of
   various classes of remote access users presents a number of
   challenges.  It is the aim of this document to explore and enumerate
   the requirements of various IPsec remote access scenarios, without
   suggesting particular solutions for them.


1.1 Requirements Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this



Kelly, Ramamoorthi          Expires July 2001                  [Page 7]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   document, are to be interpreted as described in [3].

1.2 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.
   Familiarity with RADIUS, PPP, PPTP, L2F, L2TP, and other remote
   access support protocols will also be helpful, though not strictly
   necessary.

1.3 General Terminology

   o Remote Access - this term is used to refer to the case in which
     the remote user does not necessarily reside at a fixed location,
     i.e. in which the user's IP address is not fixed, and therefore
     usually not known prior to connection establishment.

   o Secure Remote Access - this term refers to remote access which is
     secured using elements of the IPsec protocol suite.

   o IPsec Remote Access Client (IRAC)- this term is used to refer to
     the remote access user's system.

   o IPsec Remote Access Server (IRAS) - this term refers to the device
     providing access to the target network. An alternative term
     is "Security Gateway".

   o Security GateWay (SGW) - this refers to the device providing
     access to the target network. An alternative term is IRAS.

   o Virtual IP address (VIP) - this term describes an address on
     the local subnet which is assigned to a remote client,
     giving the appearance that the remote client resides on
     a local subnet.

   o Machine-Level Authentication - this term describes the
     case where the identity of a machine is verified by virtue
     of the machine's possession and application of some
     combination of authenticators. For a more complete definition,
     see section 2.

   o User-Level Authentication - this term describes the case
     where the identity of a user (as opposed to that of a machine)
     is verified by virtue of the user's possession and application
     of some combination of authenticators. For a more complete
     definition, see section 2.




Kelly, Ramamoorthi          Expires July 2001                  [Page 8]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


1.4 Document Organization

   The balance of this document is organized as follows: First, there is
   a general overview of the basic requirements categories, including
   definitions relevant to these categories. Following this is a section
   devoted to each remote access scenario. Within each of these sections
   there are subsections detailing requirements specific to that
   scenario in each of the following areas: endpoint authentication,
   remote host configuration, policy configuration, auditing, and
   intermediary traversal.

2. Overview

   In a very general sense, all secure remote access scenarios have a
   similar high-level appearance:


                                         target network
                                              |
                                              |   +---+
   +-------------+             +-----------+  |---|   |
   |remote access|  internet   | security  |  |   +---+
   |   client    |=============| gateway   |--|
   |   (IRAC)    |             |(SGW/IRAS) |  |   +---+
   +-------------+             +-----------+  |---|   |
                                              |   +---+


   In all cases, a remote client wishes to securely access resources
   either behind a SGW or on an IPsec-protected host, and/or wishes to
   provide other (specific) systems with secure access to the client's
   own resources. There are numerous details which may differ, depending
   on the particular scenario. For example, the IRAC may be within
   another corporate network, or connected to an ISP via dialup, DSL, or
   CATV media. There may be additional intermediaries between the remote
   client and the security gateway, but ultimately, all of these
   configurations may be viewed somewhat equivalently from a high level.

   In general, there are several basic categories of requirements
   relevant to secure remote access scenarios, including endpoint
   authentication, remote host configuration, security policy
   configuration, auditing, and intermediary traversal. Endpoint
   authentication refers to verification of the identities of the
   communication partners (e.g. the IRAC and the IRAS).  Remote host
   configuration refers to the device configuration parameters of the
   IRAC system. Security policy configuration refers to IPsec policy
   configuration of both the security gateway and the remote host, and
   might also be termed "access control and authorization



Kelly, Ramamoorthi          Expires July 2001                  [Page 9]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   configuration".  Auditing refers to the generation and collection of
   connection status information which is required for the purpose of
   maintaining the overall security and integrity of the connected
   networks. Intermediary traversal refers to the ability to pass
   secured traffic across intermediaries, some of which may modify the
   packets in some manner. Such intermediaries include NAPT and firewall
   devices. These various categories are treated in more detail below.


2.1 Endpoint Authentication

   Before discussing endpoint authentication with respect to remote
   access, it is important to distinguish between data source
   authentication and end user authentication. Data source
   authentication in the IPsec context consists in providing assurance
   that a network packet originates from a specific endpoint, typically
   a user, host, or application. IPsec offers mechanisms for this via AH
   or ESP. End user authentication within the IPsec context consists in
   providing assurance that the endpoint is what or who it claims to be.
   IPsec currently offers mechanisms for this as part of IKE  [IKE].

   While the two types of authentication differ, they are not unrelated.
   In fact, data source authentication relies upon endpoint
   authentication, because it is possible to inject packets with a
   particular IP address into the internet from many arbitrary
   locations, so that we cannot be certain in many instances that a
   packet actually originates from a particular host, or even from the
   network upon which that host resides.  To resolve this, one must
   first authenticate the particular endpoint somehow, and then bind the
   addressing information (e.g. IP address, protocol, port) of this
   endpoint into the trust relationship established by the
   authentication process.

   In the context of secure remote access, the authenticated entity may
   be a machine, a user (application), or both. The authentication
   methods currently supported by IPsec range from preshared secrets to
   various signature and encryption schemes employing private keys and
   their corresponding public key certificates. These mechanisms may be
   used to authenticate the end user alone, the device alone, or both
   the end user and the device. These are each discussed in more detail
   below.

2.1.1 Machine-Level Authentication

   In the case where no user input is required in order for an
   authentication credential to be used, the entity authenticated will
   primarily be the device in which the credential is stored, and the
   level of derived assurance regarding this authentication is directly



Kelly, Ramamoorthi          Expires July 2001                 [Page 10]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   related to how securely the machine's credential is maintained during
   both storage and use. That is, a shared secret or a private key
   corresponding to a public key certificate may be either stored within
   the device or contained in another device which is securely
   accessible by the device (e.g. a smartcard). If the knowledge
   required for the use of such authentication credentials is entirely
   contained within the subject device (i.e. no user input is required),
   then it is problematic to state that such credential usage
   authenticates anything other than the subject device.

   In some cases, a user may be required to satisfy certain criteria
   prior to being given access to stored credentials. In such cases, the
   level of user authentication provided by the use of such credentials
   is somewhat difficult to derive. If sufficiently strong access
   controls exist for the system housing the credential, then there may
   be a strong binding between the authorized system user and the
   credential. However, at the time the credential is presented, the
   IRAS itself has no such assurance. In order for the IRAS to derive
   additional assurance regarding the user identity, an additional user
   credential of some sort would be required. This is discussed further
   below.


2.1.2 User-Level Authentication

   In some cases, the user may possess an authentication token
   (preshared key, private key, passphrase, etc.), and may provide this
   or some derivative of this whenever authentication is required. If
   this token or derivative is delivered directly to the other endpoint
   without modification by the IRAC system, and if the IRAC system
   provides no further credentials of its own, then it is the user alone
   which has been authenticated. That is, while there may be some
   assurance as to the network address from which the user is
   originating packets, there is no assurance as to the particular
   machine from which the user is attempting access.


2.1.3 Combined User/Machine Authentication

   To authenticate both the user and the system, user input of some sort
   is required in addition to a credential which is securely stored upon
   the device. In some cases, such user input may be used in order to
   "complete" the credential stored on the device (e.g. a private key is
   password-encrypted), while in others the user's input is supplied
   independently of the stored credential. In the case where the
   passphrase is applied to the credential prior to use, the level of
   assurance derived from successful application of the credential
   varies according to your viewpoint.



Kelly, Ramamoorthi          Expires July 2001                 [Page 11]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   From the perspective of a system consisting of user, IRAC, IRAS, and
   a collection of system protections and security procedures, it may be
   said that the user has been authenticated to an extent which depends
   upon the strength of the security procedures and system protections
   which are in place. However, from the perspective of the IRAS alone,
   there is no assurance with respect to user identity. That is, schemes
   requiring that stored credentials be modified by user input prior to
   use may only be said to provide user-level authentication within the
   context of the larger system, and then, the level of assurance
   derived is directly proportional to the weakest security attribute of
   the entire system.

   When considering remote access from a general perspective,
   assumptions regarding the overall system are liable to prove
   incorrect. This is because the IRAS and the IRAC may not be within
   the same domain of control; extranet scenarios are a good example of
   this. Hence, the most desirable joint user/machine authentication
   mechanisms in this context are those which provide a high level of
   assurance to both the IRAS and the IRAC, independently of the larger
   system of which the user, IRAS, and IRAC are a part.


2.1.4 Remote Access Authentication

   In the general case for remote access, authentication requirements
   are typically asymmetric.  From the IRAC's perspective, it is
   important to ensure that the IRAS at the other end of the connection
   is indeed what it seems to be, and not some rogue system masquerading
   as the SGW. That is, the IRAC requires machine-level authentication
   for the IRAS.  This is fairly straightforward, given the
   authentication mechanisms supported by IKE and IPsec. Further, this
   sort of authentication tends to persist through time, although the
   extent of this persistence depends upon the mechanism chosen.

   While machine-level authentication for the IRAS is sufficient, this
   is not the case for the IRAC. Here, it is often important to know
   that the entity at the other end of the connection is one who is
   authorized to access local resources rather than someone who happened
   upon an unoccupied but otherwise authorized system, or a malicious
   trojan horse application on that user's system, or some other
   unauthorized entity. Authenticating the user presents different
   requirements than authenticating the user's machine; this requires
   some form of user input, and often the authentication must be
   periodically renewed.

   In situations where a high level of physical security does not exist,
   it is common to require a user-input secret as part of the
   authentication process, and then to periodically renew the



Kelly, Ramamoorthi          Expires July 2001                 [Page 12]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   authentication. Furthermore, since such circumstances may include the
   possibility of the presence of a trojan horse application on the IRAC
   system, one-time passphrase mechanisms are often advisable. Choosing
   passphrase mechanisms and renewal intervals which provide an
   acceptable level of risk, but which do not annoy the user too much,
   may be challenging. It should be obvious that even this approach
   offers limited assurance in many cases.

   Clearly, there are variable assurance levels which are attainable
   with the various endpoint authentication techniques, and none of the
   techniques discussed offer absolute assurance. Also, there are
   variations in the authentication requirements among different remote
   access scenarios. This means there is no "cookie cutter" solution for
   this problem, and that individual scenarios must be carefully
   examined in order to derive specific requirements for each. These are
   examined on a case by case basis below in the detailed scenario
   descriptions.

2.1.5 Compatibility With Legacy Mechanisms

   There are a number of currently deployed remote access mechanisms
   which were installed prior to the deployment of IPsec. Typically,
   these are dialup systems which rely upon RADIUS for user
   authentication, but there are other mechanisms as well. An ideal
   IPsec remote access solution might utilize the components of the
   underlying user authentication framework without modification.
   Inasmuch as this is possible, this should be a goal. However, there
   may be cases where this simply cannot be accomplished, due to
   security and/or other considerations. In such cases, the IPsec remote
   access framework should be designed to accommodate migration from
   these mechanisms as painlessly as is possible.

   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
       eavesdropping and replay (including the user identity)

     o single sign-on capability should be provided in configurations



Kelly, Ramamoorthi          Expires July 2001                 [Page 13]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


       employing load-balancing and/or redundancy

     o n-factor authentication mechanisms should be supported



2.2 Remote Host Configuration

   Remote host configuration refers to the network-related device
   configuration of the client system. This configuration may be fixed
   or dynamic. It may be completely provided by the administrator of the
   network upon which the remote user currently resides (e.g. the ISP),
   or it may be partially provided by that administrator, with the
   balance provided by an entity on the remote corporate network which
   the client is accessing. In general, this configuration may include
   the following:

     o IP address(es)
     o Subnet mask(s)
     o Broadcast address(es)
     o Host name
     o Domain name
     o Time offset
     o Servers (e.g. SMTP, POP, WWW, DNS/NIS, LPR,
       syslog, WINS, NTP, etc. )
     o Router(s)
     o Router discovery options
     o Static routes
     o MTU
     o Default TTL
     o Source routing options
     o IP Forwarding enable/disable
     o PMTU options
     o ARP cache timeout
     o X Windows options
     o NIS options
     o NetBIOS options
     o Vendor-specific options
     o (other options)

   Cases where such configuration is fixed are uninteresting; it is the
   cases where specific IRAC configuration occurs as a result of remote
   access with which we are concerned. For example, in some cases the
   IRAC may be assigned a "virtual address", giving the appearance that
   it resides on the target network:

                                          target net
    +------------------+                      |



Kelly, Ramamoorthi          Expires July 2001                 [Page 14]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


    |  Remote Access   |        +--------+    |   ( ~ ~ ~ ~ ~ )
    |+-------+ Client  |        |        |    |   (   IRAC    )
    ||virtual|         |        |security|    |~~~(  virtual  )
    || host  |         |--------|gateway |    |   (  presence )
    ||       |<================>|        |----|     ~ ~ ~ ~ ~
    |+-------+         |--------|        |    |
    +------------------+   ^    +--------+    |   +--------+
                           |                  |---|  local |
                         IPsec tunnel         |   |   host |
                         with encapsulated    |   +--------+
                         traffic inside


   In this case, the IRAC system begins with an externally routable
   address. An additional target network address is assigned to the
   IRAC, and packets containing this assigned address are encapsulated,
   with the outer headers containing the IRAC's routable address, and
   forwarded to the IRAS through the tunnel. This provides the IRAC with
   a virtual presence on the target network via an IPsec tunnel. Note
   that the IRAC now has two active addresses: the ISP-assigned address,
   and the VIP.

   Having obtained this virtual presence on the corporate network, the
   IRAC may now require other sorts of topology-related configuration,
   e.g. default routers, DNS server(s), etc., just as a dynamically
   configured host which physically resides upon the target network
   would. It is this sort of configuration with which this requirements
   category is concerned.



2.3 Security Policy Configuration

   Security policy configuration refers to IPsec access policies for
   both the remote access client and the security gateway. It may be
   desirable to configure access policies on connecting IRAC systems
   which will protect the target network. For example, since a client
   has access to the internet (via its routable address), other systems
   on the internet also have some level of reciprocal access to the
   client. In some cases, it may be desirable to block this internet
   access (or force it to pass through the tunnel) while the client has
   a tunneled connection to the target network. This is a matter of
   client security policy configuration.

   For the security gateway, it may also be desirable to dynamically
   adjust policies based upon the user with which a connection has been
   established. For example, say there are two remote users, named Alice
   and Bob. We wish to provide Alice with unrestricted access to the



Kelly, Ramamoorthi          Expires July 2001                 [Page 15]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   corporate network, while we wish to restrict Bob's access to specific
   segments. One way to accomplish this would be to statically assign
   internal "virtual" addresses to each user in a one-to-one mapping, so
   that each user always has the same address. Then, a particular user's
   access could be controlled via policies based upon the particular
   address. However, this does not scale well.

   A more scalable solution for remote client access control would be to
   dynamically assign IP addresses from a specific pool based upon the
   authenticated endpoint identity, with access to specific resources
   controlled by address-based policies in the SGW. This is very similar
   to the static mapping described above, except that a given group of
   users (those with identical access controls) would share a given pool
   of IP addresses (those which are granted the required access), rather
   than a given user always mapping to a given address. However, this
   also has scaling issues, though not as pronounced as for the static
   mapping.

   Alternatively, an arbitrary address could be assigned to a user, with
   the security gateway's policy being dynamically updated based upon
   the identity of the remote client (and its assigned virtual address)
   to permit access to particular resources. In these cases, the
   relevant security policy configuration is specific to the IRAS,
   rather than to the IRAC. Both IRAS and IRAC security policy
   configuration are encompassed by this requirements category.


2.4 Auditing

   Auditing is used here to refer to the collection and reporting of
   connection status information by the IRAS, for the purpose of
   maintaining the security and integrity of the network the IRAS
   protects. For remote access, the following auditing information is
   useful from a security perspective:

     o connection start time
     o connection end time

   Note that the requirement for a connection-end-time attribute implies
   the need for a connection heartbeat mechanism of some sort so that
   the IRAS can accurately determine this quantity in cases where the
   IRAC does not explicitly terminate the connection. Also note that the
   heartbeat mechanism in this case is always directed from the IRAC to
   the IRAS.

   In some cases, use of a heartbeat may negatively influence a
   connection. For example, if the heartbeat interval is very short, and
   the connection is reset after loss of very few heartbeat packets,



Kelly, Ramamoorthi          Expires July 2001                 [Page 16]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   there is a possibility that network congestion could lead to
   unnecessary connection resets. The heartbeat interval and reset
   threshold should be chosen with this in mind, and it should be
   possible to adjust these quantities either through configuration or
   negotiation.


2.5 Intermediary Traversal

   Intermediary traversal is used here to refer to passing a secured
   data stream through an intermediary such as a firewall or NAPT
   device. In the case of firewalls, numerous deployed products do not
   recognize the IPsec protocol suite, making it difficult (sometimes
   impossible) to configure them to pass it through. In such cases, a
   mechanism is required for making the data stream appear to be of a
   type which the firewall is capable of managing.

   In the case of NAPT devices, there are a number of issues with
   attempting to pass an encrypted or authenticated data stream. For
   example, NAPT devices typically modify the source IP address and
   UDP/TCP port of outgoing packets, and the destination IP address and
   UDP/TCP port of incoming packets, and in some cases, they modify
   additional fields in the data portion of the packet. Such
   modifications render the use of the AH protocol impossible. In the
   case of ESP, the UDP/TCP port fields fields are sometimes unreadable
   and always unmodifiable, making meaningful translation by the NAPT
   device impossible. There are numerous other protocol-field
   combinations which suffer similarly. This requirements category is
   concerned with these issues.


3. Scenarios

   There are numerous remote access scenarios possible using IPsec. This
   section contains a brief summary enumeration of these, followed by a
   subsection devoted to each which explores the various requirements in
   terms of the categories defined above.

   The following scenarios are discussed:

     o dialup/dsl/cablemodem telecommuters using their
       systems to access remote resources

     o extranet users using their corporate desktop systems to
       access the remote company network of a business partner

     o extranet users using their own laptop within another
       company's network to access their home corporate network



Kelly, Ramamoorthi          Expires July 2001                 [Page 17]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     o extranet users using a business partner's system (on that
       partner's network) to access their home corporate network

     o road warriors using laptop systems to access target
       resources via an arbitrary ISP dialup connection

     o remote users using a borrowed system (e.g. an airport
       kiosk) to access corporate resources


3.1 Telecommuters (Dialup/DSL/Cablemodem)

   The telecommuter scenario is one of the more common remote access
   scenarios. The convenience and wide availability of internet access
   makes this an attractive option under many circumstances. Users may
   access the internet from the comfort of their homes or hotel rooms,
   and using this internet connection, access the resources of a
   corporate network. In some cases, dialup accounts are used to provide
   the initial internet access, while in others some type of "always-on"
   connection such as a DSL or CATV modem is used.

   The dialup and always-on cases are very similar, with two significant
   differences: address assignment mechanism, and connection duration.
   In most dialup cases, the IRAC's IP address is dynamically assigned
   as part of connection setup, and with fairly high likelihood, it is
   different each time the IRAC connects. DSL/CATV users, on the other
   hand, often have static IP addresses assigned to them, although
   dynamic assignment is on the increase. As for connection duration,
   dialup remote access connections are typically short-lived, while
   always-on connections may maintain remote access connections for
   significantly longer periods of time.

   The general configuration in either case looks like this:

                                              corporate net

                                                  |  +----+
     +-----+   +-----+      /---/ internet +---+  |--|    |
     |IRAC |---|modem|------|ISP|==========|SGW|--|  +----+
     +-----+   +-----+      /---/          +---+  |
                                                  |


   An alternative to this configuration entails placing a security
   gateway between the user's system and the modem, in which case this
   added SGW becomes the IRAC. This is currently most common in cases
   where DSL/CATV connections are used.




Kelly, Ramamoorthi          Expires July 2001                 [Page 18]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


3.1.1 Endpoint Authentication Requirements

   The authentication requirements of this scenario depend in part upon
   the general security requirements of the network to which access is
   to be provided. Assuming that the target SGW is physically secure,
   machine authentication for the SGW is sufficient. If this assumption
   regarding physical security is incorrect, it is not clear that
   stronger authentication for the SGW could be guaranteed, and
   derivation of an effective mechanism for that case is beyond the
   scope of this document.

   For the IRAC, there are numerous threats to the integrity of the user
   authentication process. Due to the open nature of common consumer
   operating systems, some of these threats are quite difficult to
   protect against. For example, it is very difficult to assert with any
   level of certainty that a single user system which permits the
   downloading and running of arbitrary applications from the internet
   has not been compromised, and that a covert application is not
   monitoring and interacting with the user's data at any point in time.

   However, there are 2 general threats we might realistically hope to
   somehow mitigate with appropriate authentication mechanisms if we can
   assume that the system has not been compromised in this manner.
   First, there is the possibility that a secure connection is
   established for a particular user, but that someone other than the
   intended user is currently using that connection. Second, there is
   the possibility that the user's credential (password, hardware token,
   etc.)  has been somehow compromised, and is being used by someone
   other than the authorized user to gain access.

   Mitigation of the first threat, the possibility that someone other
   than the authorized user is currently using the connection,  requires
   periodic renewal of user authentication. It should be clear that
   machine authentication will not suffice in this case, and that
   requiring periodic re-entry of an unchanging user password (which may
   be written on a post-it note which is stuck to the user's monitor)
   will have limited effectiveness. Convincing verification of the
   continued presence of the authorized user will, in many cases,
   require periodic application of a time-variant credential.

   Mitigation of the second threat, credential compromise, is difficult,
   and depends upon a number of factors. If the IRAC system is running a
   highly secure operating system, then a time-variant credential may
   again offer some value.  A static password is clearly deficient in
   this scenario, since it may be subject to either online or offline
   guessing, and eventually compromised - which is the threat we are
   attempting to mitigate. However, if the IRAC operating system is not
   hardened,  the use of a time-variant credential is only effective if



Kelly, Ramamoorthi          Expires July 2001                 [Page 19]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   simultaneous access from more than one location is forbidden, if the
   credential generation mechanism is not easily compromised.

   A second approach to the credential compromise problem entails using
   a PKI-based credential which is stored within a secure container of
   some sort, and which requires some user interaction prior to
   operation (e.g. a smartcard). If such a credential requires periodic
   user interaction to continue operating (e.g. pin re-entry), this may
   help to limit the access an unauthorized user who happens upon a
   connected but unattended system realizes. However, choosing an
   acceptable refresh interval is a difficult problem, and if the pin is
   not time-variant, this provides limited additional assurance.

   To summarize, the following are the authentication requirements for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for user authentication SHOULD be provided
     o support for either user or machine authentication MUST
       be provided
     o support for user authentication MUST be provided if
       protection from unauthorized connection use is desired.
     o if user authentication is provided for short-lived dialup
       connections, periodic renewal MAY occur
     o if user authentication is provided for always-on connections,
       periodic renewal SHOULD occur



3.1.2 Device Configuration Requirements

   There are 2 possibilities for device configuration in the
   telecommuter scenario: either access to the target network is
   permitted for the native ISP-assigned address of the telecommuter's
   system, or the telecommuter's system is assigned a virtual address
   from within the target address space. In the first case, there are no
   device configuration requirements which are not already satisfied by
   the ISP.  However, this case is the exception, rather than the rule.

   The second case is far more common, due to the numerous benefits
   derived by providing the IRAC with a virtual presence on the target



Kelly, Ramamoorthi          Expires July 2001                 [Page 20]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   network. For example, the virtual presence allows the client to
   receive subnet broadcasts, which permits it to use WINS on the target
   network. In addition, if the IRAC tunnels all traffic to the target
   network, then the target policy can be applied to internet traffic
   to/from the IRAC.

   In this case, the IRAC requires, at minimum, assignment of a
   corporate IP address. Typically, the IRAC requires anywhere from
   several more to many more elements of configuration information,
   depending upon the corporate network's level of topological
   complexity. For a fairly complete list, see section 2.2.

   To summarize, the following are the device configuration requirements
   for the IRAC:

     o support for a virtual IP (VIP) address MAY be provided
     o if VIP support is provided, support for all device-related
        parameters listed in section 2.2 above SHOULD be provided
     o support for address assignment based upon authenticated
       identity MAY be provided
     o if authenticated address assignment is not supported, an
       identity-based dynamic policy update mechanism such as
       is described in [ARCH] MUST be supported.


3.1.3 Policy Configuration Requirements

   In terms of IRAC policy configuration, the most important issue
   pertains to whether the IRAC has direct internet access enabled (for
   browsing, etc.) while a connection to the corporate network exists.
   This is important since the fact that the IRAC has access to sites on
   the internet implies that those sites have some level of reciprocal
   access to the IRAC. It may be desirable to completely eliminate this
   type of access while a tunnel is active.

   Alternatively, the risks may be mitigated somewhat by forcing all
   non-vpn packets leaving the IRAC to first traverse the tunnel to the
   target network, where they may be subjected to the target's policy.
   A second approach which carries a bit less overhead entails modifying
   the IRAC's policy configuration to reflect that of the remote network
   during the time the IRAC is connected to it via the tunnel. In this
   case, traffic is not forced to loop through the target site prior to
   exiting or entering the IRAC. This requires some sort of policy
   download (or modification) capability as part of the SA establishment
   process. A third approach is to provide a configuration variable for
   the IRAC which permits specification of "tunnel-all", or "block all
   traffic not destined for the target network while the SA is up".




Kelly, Ramamoorthi          Expires July 2001                 [Page 21]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   In terms of IRAS configuration, it may be necessary to dynamically
   update the security policy database (SPD) when the remote user
   connects. This is because transit selectors must be based upon
   network address parameters, but these cannot be known a priori in the
   remote access case. As is noted above, this may be avoided by
   provision of a mechanism which permits address assignment based upon
   authenticated identity.

   To summarize, the following are the policy configuration requirements
   for the IRAS and IRAC:

   IRAS
   ----

     o dynamic policy update mechanism based upon identity and
       assigned address MAY be supported.

     o if address assignment-based policy update mechanism is
       not supported, address assignment based upon authenticated
       identity SHOULD be supported.


   IRAC
   ----

     o IRAC SHOULD provide ability to configure for "tunnel-all"
       and/or "block-all" for traffic not destined for the
       remote network to which IPsec remote access is being
       provided.

     o support for dynamic IRAS update of IRAC policy MAY be provided.


3.1.4 Auditing Requirements

   For telecommuter sessions, session start/end times must be collected.
   Reliable derivation of session end time requires that the IRAC
   somehow periodically signify that the connection remains active. This
   is implied if the IRAS receives data from the IRAC over the
   connection, but in cases where no data is sent for some period of
   time, a signaling mechanism is required by which the IRAC indicates
   that the connection remains in use.

3.1.5 Intermediary Traversal Requirements

   If the address assigned by the ISP to the IRAC system is globally
   routable, and no intermediate devices between the IRAC and the IRAS
   perform NAPT operations on the data stream, then there are no



Kelly, Ramamoorthi          Expires July 2001                 [Page 22]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   additional requirements.  If NAPT operations are performed on the
   data stream, some mechanism must be provided in order to render these
   modifications transparent to the IPsec implementation.


3.2 Corporate to Remote Extranet

   Extranets are becoming increasingly common, especially as IPsec
   becomes more widely deployed. In this scenario, a user from one
   corporation uses a local corporate system to access resources on
   another corporation's network. Typically, these corporations are
   cooperating on some level, but not to the degree that unbridled
   access between the two networks would be acceptable. Hence, this
   scenario is characterized by limited access. The general topological
   appearance is similar to this:


          CORP A                                CORP B
             |                                      |
    +----+   |                                      |  +-----+
    |USER|---|                                      |--| S1  |
    +----+   |   +------++              ++------+   |  +-----+
             |---|SGW/FW||===internet===||SGW/FW|---|
             |   +------++              ++------+   |  +-----+
             |     SGW-A                   SGW-B    |--| S2  |
             |                                      |  +-----+


   This is purposely simplified in order to illustrate some basic
   characteristics without getting bogged down in details. At the edge
   of each network is a combination security gateway and firewall
   device.  These are labeled "SGW-A" and "SGW-B". In this diagram,
   corporation B wishes to provide a user from corporation A with access
   to servers S1 and/or S2. This may be accomplished in one of several
   different ways:

   1) an end-to-end SA is formed from USER to S1 or S2

   2) a tunnel-mode SA is formed between SGW-A and SGW-B which only
      permits traffic between S1/S2 and USER.

   3) a tunnel-mode SA is formed between USER and SGW-B which only
      permits traffic between S1/S2 and USER.

   These various cases are individually discussed with respect to each
   requirements category below.

3.2.1 Authentication Requirements



Kelly, Ramamoorthi          Expires July 2001                 [Page 23]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   For the corporate extranet scenario, the authentication requirements
   vary slightly depending upon the manner in which the connection is
   accomplished. If only a particular user is permitted to access S1/S2,
   then user-level authentication is required. If connection types (1)
   or (3) are used, this may be accomplished in the same manner as it
   would be for a telecommuter. If connection type (2) is used, one of
   two things must occur: either SGW-A must provide some local mechanism
   for authenticating USER and SGW-B must trust this mechanism, or SGW-B
   must have some mechanism for authenticating USER independently of
   SGW-A.

   If access is permitted for anyone within corporation A, then machine
   authentication will suffice. However, this is highly unlikely. A
   slightly more likely situation might be one in which access is
   permitted to anyone within a particular organizational unit in
   corporation A. This case is very similar the single user access case
   discussed above, and essentially has the same requirements in terms
   of the mechanism required for SGW-A, although machine authentication
   might suffice if the organizational unit which is permitted access
   has a sufficient level of physical security. Again, this requires
   that corporation B trust corporation A in this regard.

   To summarize, the following are the authentication requirements for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for either user or machine authentication MUST
       be provided
     o support for a combination of user and machine authentication
       SHOULD be provided
     o if user authentication is used, periodic renewal SHOULD occur


3.2.2 Device Configuration Requirements

   It is possible that corporation B would want to assign a virtual
   address to USER for the duration of the connection. The only way this
   could be accomplished would be if USER were a tunnel endpoint (e.g.
   in cases (1) and (3)). It is not clear what benefits, if any, this
   would offer.




Kelly, Ramamoorthi          Expires July 2001                 [Page 24]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   To summarize, the following are the device configuration requirements
   for the IRAC:

     o support for a virtual address MAY be provided
     o if VIP support is provided, support for all device-related
       parameters listed in section 2.2 above SHOULD be supported
     o support for address assignment based upon authenticated
       identity SHOULD be supported
     o if authenticated address assignment is not supported, an
       identity-based dynamic policy update mechanism such as
       is described in [ARCH] MUST be supported.


3.2.3 Policy Configuration Requirements

   Any of the cases discussed above would present some static policy
   configuration requirements. Case (1) would require that SGW-A and
   SGW-B permit IPsec traffic to pass between USER and S1/S2. Case (3)
   would have similar requirements, except that the IPsec traffic would
   be between USER and SGW-B. Case (2) would require that the
   appropriate transit traffic be secured between USER and S1/S2.

   None of these cases require dynamic policy configuration.

3.2.4 Auditing Requirements

   For cases (1) and (3),  session start/end times must collected.
   Reliable derivation of session end time requires that the IRAC
   somehow periodically signify that the connection remains active. This
   is implied if the IRAS receives data from the IRAC over the
   connection, but in cases where no data is sent for some period or
   time, a signaling mechanism is required by which the IRAC indicates
   that the connection remains in use.

   For case (2), the type(s) of required auditing data would depend upon
   whether traffic from multiple users were aggregated within a single
   tunnel or not. If so, the notion of individual connection start/stop
   times would be lost. If such measures are desired, this requires that
   per-user tunnels be set up between SGW-A and SGW-B, and that some
   sort of timeout interval be used to cause tunnel teardown when
   traffic does not flow for some interval of time.

3.2.5 Intermediary Traversal Requirements

   If the address assigned by the host network to the IRAC system is
   globally routable, and no intermediate devices between the IRAC and
   the IRAS perform NAPT operations on the data stream, then there are
   no additional requirements in this regard. If NAPT operations are



Kelly, Ramamoorthi          Expires July 2001                 [Page 25]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   performed on the data stream, some mechanism must be provided in
   order to render these modifications transparent to the IPsec
   implementation.

   If a firewall situated at the edge of the host network cannot be
   configured to pass protocols in the IPsec suite, then some mechanism
   must be provided which converts the data stream to one which the
   firewall may be configured to pass.  If the firewall can be
   configured to pass IPsec protocols, then this must be accomplished
   prior to connection establishment.


3.3 Extranet Laptop to Home Corporate Net

   The use of a laptop while visiting another corporation presents
   another increasingly common extranet scenario. In this case, a user
   works temporarily within another corporation, perhaps as part of a
   service agreement of some sort. The user brings along a CORP-A laptop
   which is assigned a CORP-B address either statically or dynamically,
   and the user wishes to securely access resources on CORP-A's network
   using this laptop. This scenario has the following appearance:

          CORP A                                CORP B
             |                                      |
    +----+   |                                      |  +--------+
    |POP |---|                                      |--| CORP-A |
    +----+   |   +------++              ++------+   |  | laptop |
             |---|SGW/FW||===internet===||SGW/FW|---|  +--------+
             |   +------++              ++------+   |
    +----+   |     SGW-A                   SGW-B    |
    |FTP |---|                                      |
    +----+   |                                      |


   This is very similar to the telecommuter scenario, but it differs in
   several important ways. First, in this case there is often a SGW
   and/or firewall at the edge of CORP-B's site. Second, there may be a
   significantly increased risk that a long-lived connection could
   become accessible to someone other than the intended user.

3.3.1 Authentication Requirements

   In most cases, the only acceptable connections from CORP-A's
   perspective are between the laptop and either SGW-A or the CORP-A
   servers the laptop wishes to access. Most of the considerations
   applied to the telecommuter also apply here, and user-level
   authentication is required to provide assurance that the user who
   initiated the connection is still the active user. As an added



Kelly, Ramamoorthi          Expires July 2001                 [Page 26]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   precaution, a combination of user-level and machine-level
   authentication may be warranted in some cases. Further, in either
   case this authentication should be renewed frequently.

   To summarize, the following are the authentication requirements for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for machine authentication SHOULD be provided
     o support for user authentication MUST be provided
     o support for a combination of user and machine authentication
       SHOULD be provided
     o periodic renewal of user authentication MUST occur



3.3.2 Device Configuration Requirements

   The device configuration requirements in this scenario are the same
   as for the telecommuter, i.e. the laptop may be assigned a virtual
   presence on the corporate network, and if so, will require full
   infrastructure configuration.

   To summarize, the following are the device configuration requirements
   for the IRAC:

     o support for a virtual address MAY be provided
     o if VIP support is provided, support for all device-related
       parameters listed in section 2.2 above SHOULD be supported
     o support for address assignment based upon authenticated
       identity SHOULD be supported
     o if authenticated address assignment is not supported, an
       identity-based dynamic policy update mechanism such as
       is described in [ARCH] MUST be supported.


3.3.3 Policy Configuration Requirements

   The policy configuration requirements in this scenario differ from
   those of the telecommuter, in that the laptop cannot be assigned a
   policy which requires all traffic to be forwarded to CORP-A via the



Kelly, Ramamoorthi          Expires July 2001                 [Page 27]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   tunnel. This is due to the fact that the laptop has a CORP-B address,
   and as such, may have traffic destined to CORP-B. If this traffic
   were tunneled to CORP-A, there might be no return path to CORP-B
   except via the laptop. On the other hand, internet-bound traffic
   could be subjected to this restriction if desired, and/or all traffic
   other than that between CORP-A and the laptop could be blocked for
   the duration of the connection.

   IRAC
   ----

     o support for IRAS update of IRAC policy MAY be provided.

     o if IRAS update of IRAC policy is not supported, IRAC MAY
       support IRAS directives to "block-all" for non-tunneled
       traffic.

     o IRAC SHOULD provide ability to configure for "tunnel-all"
       and/or "block-all" for traffic not destined for the
       remote network to which IPsec remote access is being
       provided.



3.3.4 Auditing Requirements

     The auditing requirements in this scenario are the same as for the
     telecommuter scenario. Session start/end times must collected.
     Reliable derivation of session end time requires that the IRAC
     somehow periodically signify that the connection remains active.
     This is implied if the IRAS receives data from the IRAC over the
     connection, but in cases where no data is sent for some period or
     time, a signaling mechanism is required by which the IRAC indicates
     that the connection remains in use.


3.3.5 Intermediary Traversal Requirements

     If the address assigned by the host network to the IRAC system is
     globally routable, and no intermediate devices between the IRAC and
     the IRAS perform NAPT operations on the data stream, then there are
     no additional requirements in this regard. If NAPT operations are
     performed on the data stream, some mechanism must be provided in
     order to render these modifications transparent to the IPsec
     implementation.

     If a firewall situated at the edge of the host network cannot be
     configured to pass protocols in the IPsec suite, then some



Kelly, Ramamoorthi          Expires July 2001                 [Page 28]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     mechanism must be provided which converts the data stream to one
     which the firewall may be configured to pass.  If the firewall can
     be configured to pass IPsec protocols, then this must be
     accomplished prior to connection establishment.


3.4 Extranet Desktop to Home Corporate Net

   This is very similar to the extranet laptop scenario discussed above,
   except that a higher degree of trust for CORP-B is required by CORP-
   A.  This scenario has the following appearance:

           CORP A                                CORP B
             |                                      |
    +----+   |                                      |  +--------+
    |POP |---|                                      |--| CORP-B |
    +----+   |   +------++              ++------+   |  |desktop |
             |---|SGW/FW||===internet===||SGW/FW|---|  +--------+
             |   +------++              ++------+   |
    +----+   |     SGW-A                   SGW-B    |
    |FTP |---|                                      |
    +----+   |                                      |



3.4.1 Authentication Requirements

   The authentication requirements for the desktop extranet scenario are
   very similar to those of the extranet laptop scenario discussed
   above.  The primary difference lies in the authentication type which
   may be used, i.e. in the laptop case, CORP-A can derive some
   assurance that the connection is coming from one of CORP-A's systems
   if a securely stored machine credential is stored on and used by on
   the laptop. In the desktop case this is not possible, since CORP-A
   does not own the IRAC system.

   To summarize, the following are the authentication requirements for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for machine authentication MAY be provided



Kelly, Ramamoorthi          Expires July 2001                 [Page 29]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     o support for user authentication MUST be provided
     o support for a combination of user and machine authentication
       MAY be provided
     o periodic renewal of user authentication MUST occur

3.4.2 Device Configuration Requirements

     The device configuration requirements in this scenario are the same
     as for the laptop extranet scenario, i.e. the desktop system may be
     assigned a virtual presence on the corporate network, and if so,
     will require full infrastructure configuration. However, this seems
     less likely than in the laptop scenario, given CORP-A's lack of
     control over the software configuration of CORP-B's desktop system.


3.4.3 Policy Configuration Requirements

     The policy configuration requirements are quite similar to those of
     the extranet laptop, except that in this scenario there is even
     less control over CORP-B's desktop than there would be over the
     laptop. This means it may not be possible to restrict traffic in
     any way at the desktop system.

3.4.4 Auditing Requirements

     The auditing requirements in this scenario are the same as for the
     telecommuter scenario. Session start/end times must collected.
     Reliable derivation of session end time requires that the IRAC
     somehow periodically signify that the connection remains active.
     This is implied if the IRAS receives data from the IRAC over the
     connection, but in cases where no data is sent for some period or
     time, a signaling mechanism is required by which the IRAC indicates
     that the connection remains in use.

3.4.5 Intermediary Traversal Requirements

     If the address assigned by the host network to the IRAC system is
     globally routable, and no intermediate devices between the IRAC and
     the IRAS perform NAPT operations on the data stream, then there are
     no additional requirements in this regard. If NAPT operations are
     performed on the data stream, some mechanism must be provided in
     order to render these modifications transparent to the IPsec
     implementation.

     If a firewall situated at the edge of the host network cannot be
     configured to pass protocols in the IPsec suite, then some
     mechanism must be provided which converts the data stream to one
     which the firewall may be configured to pass.  If the firewall can



Kelly, Ramamoorthi          Expires July 2001                 [Page 30]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     be configured to pass IPsec protocols, then this must be
     accomplished prior to connection establishment.



3.5 Remote Dialup Laptop (Road Warrior) Access

     This is a very common remote access scenario, and is virtually
     indistinguishable from the telecommuter scenario, except that the
     connections are typically dialup only, and hence, short-lived.

     Refer to section 3.1.1 for details.


3.6 Third Party System to Target Network

     This scenario entails a traveling user connecting to the target
     network using a system provided by a third party. A commonly cited
     example is an airport kiosk. This looks very similar to the
     extranet desktop scenario, except that in the extranet scenario,
     CORP-A might have a trust relationship with CORP-B, whereas in this
     scenario, CORP-A may not trust a third-party system. Note that a
     trust relationship between CORP-A and the owner of the third-party
     system (TPS) may exist, but in many cases will not.


3.6.1 Authentication Requirements

     There are two variations to this scenario. In the first, no trust
     relationship exists between the target network and the provider of
     the borrowed system. In the second, some trust relationship does
     exist. In the case where no trust relationship exists, machine
     authentication is out of the question, as it is meaningless in this
     context. Further, since such a system could easily capture a
     passphrase, use of a static passphrase would seem to be ill-
     advised.

     If a one-time passphrase were used, this would mitigate the risk of
     passphrase capture by the third-party system. On the other hand, if
     it is acknowledged that such capture is a real threat (i.e. the
     system itself is malicious), then it must also be recognized that
     any data transmitted and received via the resulting session would
     not be confidential or reliable with respect to this malicious
     system, and that the system could not be trusted to have actually
     disconnected when the user walks away. This suggests that accessing
     non-trivial information from such a system would be imprudent.

     Another possible user authentication option would be a smartcard.



Kelly, Ramamoorthi          Expires July 2001                 [Page 31]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     However, many smartcards require a pin or passphrase to "unlock"
     them, in some cases requiring that this be entered via the keyboard
     of the accessing system. This requires some level of trust in the
     TPS to not record the pin. Hence, this approach suffers from
     drawbacks similar to those of the static passphrase in this regard.
     The primary difference would be that the pin/passphrase could not
     be used alone for access in the smartcard case.

     In cases where a trust relationship with the owner of the TPS
     exists, the trust level would modulate the risk levels discussed
     above.  For example, if a sufficient level of trust for the system
     owner exists, use of a static passphrase might present no more risk
     than if this were permitted from a system owned by the accessed
     corporation. However, the primary benefit of such a trust
     relationship would be derived from the ability to authenticate the
     machine from which the user is attempting access.  For example, a
     security policy requiring that remote access only be permitted with
     combined user/machine authentication might be effected, with
     further control regarding which machines were allowed.

     An additional issue to be dealt with in either case pertains to
     verification of the identity of the IRAS. If the IRAC were to be
     misdirected somehow, a man in the middle attack could be effected,
     with the obtained password being then used for malicious access to
     the true IRAS. Note that even a one-time password mechanism offers
     little protection in this case. In order to avert such an attack,
     the TPS must possess some certifiable or secret knowledge of the
     IRAS prior to attempting to connect, and the user must trust the
     TPS to accurately verify this information. Note that in the case
     where no trust relationship exists, this is not possible.

     To summarize, the following are the authentication requirements for
     the IRAS and IRAC:

     IRAS
     ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o in cases where no trust relationship exists between the
       accessed network and the system owner, sensitive data
       SHOULD NOT be transmitted in either direction.
     o in cases where a trust relationship exists between the
       accessed network and the system owner, machine authentication
       SHOULD be supported.



Kelly, Ramamoorthi          Expires July 2001                 [Page 32]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     o in cases where a trust relationship exists between the
       accessed network and the system owner, a static passphrase
       MAY be used in conjunction with machine-level authentication
       of the IRAC system.
     o frequent renewal of user authentication MUST occur



3.6.2 Device Configuration Requirements

     None.

3.6.3 Policy  Configuration Requirements

     None.

3.6.4 Auditing Requirements

     The auditing requirements in this scenario are the same as for the
     telecommuter scenario. Session start/end times must collected.
     Reliable derivation of session end time requires that the IRAC
     somehow periodically signify that the connection remains active.
     This is implied if the IRAS receives data from the IRAC over the
     connection, but in cases where no data is sent for some period of
     time, a signaling mechanism is required by which the IRAC indicates
     that the connection remains in use.

3.6.5 Intermediary Traversal Requirements

     If the address of the IRAC system is globally routable, and no
     intermediate devices between the IRAC and the IRAS perform NAPT
     operations on the data stream, then there are no additional
     requirements in this regard. If NAPT operations are performed on
     the data stream, some mechanism must be provided in order to render
     these modifications transparent to the IPsec implementation.


4. Scenario Commonalities

     As we examine the various remote access scenarios, a general set of
     common requirements emerge. Following is a summary:

     o Support for user authentication is required in almost
       all scenarios

     o Machine authentication for the IRAS is required in all
       scenarios




Kelly, Ramamoorthi          Expires July 2001                 [Page 33]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


     o A mechanism for providing device configuration for the
       IRAC is required in most scenarios. Such a mechanism must
       be extensible.

     o Machine authentication for IRAC is generally only useful
       when combined with user authentication. Combined user and
       and machine authentication is useful in some scenarios.

     o Dynamic IRAC policy configuration is useful in several
       scenarios.

     o Most scenarios require auditing for session start/stop
       times.

     o An intermediary traversal mechanism may be required in
       any of the scenarios.


5. Security Considerations

   The topic of this document is secure remote access. Security
   considerations are discussed throughout the document.

6. Editors' Addresses

   Scott Kelly
   RedCreek Communications
   3900 Newpark Mall Road
   Newark, CA 94560 USA
   email: skelly@redcreek.com
   Telephone: +1 (510) 745-3969

   Sankar Ramamoorthi
   Nexsi
   1959 Concourse Drive
   San Jose, CA 95131 USA
   E-mail: sankar@nexsi.com
   Telephone: +1 (408) 579-5718


7. References

   [ARCH]      Kent, S., and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

   [KEYWORDS]  Bradner, S., "Key Words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.




Kelly, Ramamoorthi          Expires July 2001                 [Page 34]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   [RADIUS]    C. Rigney, A. Rubens, W. Simpson, S. Willens,
               "Remote Authentication Dial In User Service
               (RADIUS)", RFC2138

   [IKE]       Harkins, D., and D. Carrel, "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.

   [L2TP]      Townsley, M., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
               Palter, B., "Layer Two Tunneling Protocol L2TP", RFC2661,
               August, 1999

   [PPP]       Simpson, W., "The Point-to-Point Protocol (PPP)", Std 51,
               RFC1661, July 1994

   [PPTP]      Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
               Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
               RFC 2637, July 1999


8. Acknowledgements

   The editors would like to acknowledge the many helpful comments of Sara
   Bitan, Steve Kent, Mark Townsley, and other members of the ipsra working
   group who have made helpful comments on this work.


9. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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



Kelly, Ramamoorthi          Expires July 2001                 [Page 35]


Internet Draft      <draft-ietf-ipsra-reqmts-03.txt>       January, 2001


   "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.



Appendix A: Change Log

   00 to 01:

   o delete mobility requirements
   o add accounting requirements
   o extensively modify discussion of endpoint authentication, and
     machine vs. user authentication
   o delete roaming/wireless users and user-to-user connections from
     Scenarios bullet list
   o Add discussion of trojan horse applications to telecommuter scenario
   o add statement about encouraging migration to PKI-based systems to
     legacy compatibility section.
   o clarified language in section 2.3 (Security Policy Configuration)

   01 to 02:

   o add n-factor authentication to general requirements
   o change "accounting" to "auditing"
   o delete incoming/outgoing octet counts from auditing requirements
   o added intermediary traversal requirements
   o numerous general edits for clarity

   02 to 03:

   o minor edits throughout
   o significantly modified introduction to provide discussion
     of L2TP/IPsec
   o replaced "corporate" with "target" when referring to the
     network the IRAS protects
   o modified discussion in section 3.1.1
   o changed SHOULD to MAY in section 3.2.2, support for address
     assignment based on authenticated identity
   o change "public" to "third-party" in section 3.6








Kelly, Ramamoorthi          Expires July 2001                 [Page 36]