GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3457

Network Working Group S. Kelly Request for Comments: 3457 Airespace Category: Informational S. Ramamoorthi

                                                      Juniper Networks
                                                          January 2003
           Requirements for IPsec Remote Access Scenarios

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 IPsec offers much promise as a secure remote access mechanism.
 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.

Table of Contents

 1. Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
    1.1 Requirements Terminology . . . . . . . . . . . . . . . .  3
    1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . .  3
    1.3 General Terminology  . . . . . . . . . . . . . . . . . .  4
    1.4 Document Content and Organization  . . . . . . . . . . .  4
 2. Overview  . . . . . . . . . . . . . . . . . . . . . . . . .   5
    2.1 Endpoint Authentication . . . . . . . . . . . . . . . .   6
       2.1.1 Machine-Level Authentication . . . . . . . . . . .   7
       2.1.2 User-Level Authentication  . . . . . . . . . . . .   7
       2.1.3 Combined User/Machine Authentication . . . . . . .   8
       2.1.4 Remote Access Authentication . . . . . . . . . . .   8
       2.1.5 Compatibility With Legacy Remote Access Mechanisms   9
    2.2 Remote Host Configuration  . . . . . . . . . . . . . . . 10
    2.3 Security Policy Configuration  . . . . . . . . . . . . . 11
    2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . 12
    2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . 13

Kelly & Ramamoorthi Informational [Page 1] RFC 3457 IPsec Remote Access Scenarios January 2003

 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . .  13
    3.1 Telecommuters (Dialup/DSL/Cablemodem)  . . . . . . . . . 14
       3.1.1 Endpoint Authentication Requirements . . . . . . .  15
       3.1.2 Device Configuration Requirements  . . . . . . . .  16
       3.1.3 Policy Configuration Requirements  . . . . . . . .  17
       3.1.4 Auditing Requirements  . . . . . . . . . . . . . .  18
       3.1.5 Intermediary Traversal Requirements  . . . . . . .  18
    3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . 19
       3.2.1 Authentication Requirements  . . . . . . . . . . .  19
       3.2.2 Device Configuration Requirements  . . . . . . . .  20
       3.2.3 Policy Configuration Requirements  . . . . . . . .  21
       3.2.4 Auditing Requirements  . . . . . . . . . . . . . .  21
       3.2.5 Intermediary Traversal Requirements  . . . . . . .  21
    3.3 Extranet Laptop to Home Corporate Net . . . . . . . . .  22
       3.3.1 Authentication Requirements  . . . . . . . . . . .  22
       3.3.2 Device Configuration Requirements  . . . . . . . .  23
       3.3.3 Policy Configuration Requirements  . . . . . . . .  23
       3.3.4 Auditing Requirements  . . . . . . . . . . . . . .  24
       3.3.5 Intermediary Traversal Requirements  . . . . . . .  24
    3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . 25
       3.4.1 Authentication Requirements  . . . . . . . . . . .  25
       3.4.2 Device Configuration Requirements  . . . . . . . .  26
       3.4.3 Policy Configuration Requirements  . . . . . . . .  26
       3.4.4 Auditing Requirements  . . . . . . . . . . . . . .  26
       3.4.5 Intermediary Traversal Requirements  . . . . . . .  26
    3.5 Public System to Target Network . . . . . . . . . . . .  27
       3.5.1 Authentication Requirements  . . . . . . . . . . .  27
       3.5.2 Device Configuration Requirements  . . . . . . . .  28
       3.5.3 Policy  Configuration Requirements . . . . . . . .  28
       3.5.4 Auditing Requirements  . . . . . . . . . . . . . .  29
       3.5.5 Intermediary Traversal Requirements  . . . . . . .  29
 4. Scenario Commonalities  . . . . . . . . . . . . . . . . . .  29
 5. Security Considerations . . . . . . . . . . . . . . . . . .  30
 6. References  . . . . . . . . . . . . . . . . . . . . . . . .  30
 7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . .  30
 8. Editors' Addresses. . . . . . . . . . . . . . . . . . . . .  30
 9. Full Copyright Statement  . . . . . . . . . . . . . . . . .  31

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 target 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].

Kelly & Ramamoorthi Informational [Page 2] RFC 3457 IPsec Remote Access Scenarios January 2003

 Note that for such access, it has often been assumed that the
 communications infrastructure supporting the ISP connection (the
 PSTN) is relatively secure, and poses no significant threats to
 communications integrity or confidentiality.  Based on this
 assumption, connection security has been limited to access control at
 the NAS based on username/passphrase pairs.  In reality, PSTN dialup
 connections have never been impervious to a determined adversary.
 The availability of widespread broadband access, in concert with the
 desire to reduce the cost of PSTN toll access, have driven the
 development of Internet-based remote access mechanisms.  In some
 cases, PPP-based tunneling mechanisms have been used to provide
 remote access by allowing the dial user to first access a local ISP
 account, and then tunnel an additional PPP connection over the
 Internet into the target network.  In the case of broadband users,
 such connections are tunneled directly over the Internet.  While
 these mechanisms have been lacking in terms of security features, the
 increasing availability of IPsec renders it possible to provide more
 secure remote access to the remote resources via the Internet.
 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
 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.

Kelly & Ramamoorthi Informational [Page 3] RFC 3457 IPsec Remote Access Scenarios January 2003

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 from a
    subnet local to the target network which is assigned to a remote
    client, giving the appearance that the remote client actually
    resides on the target network.
 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.
 o  NAPT - Network Address/Port Translation

1.4 Document Content and Organization

 This document, while initially intended to simply outline
 requirements for various remote access scenarios, has come to include
 somewhat more than this.  This document has evolved from discussion
 within the IPsec Remote Access (IPSRA) working group.  As a result,
 it in some respects documents the evolution of this thought process.
 While this represents a departure from the typical form of a

Kelly & Ramamoorthi Informational [Page 4] RFC 3457 IPsec Remote Access Scenarios January 2003

 requirements document, the associated historical context should prove
 useful in interpreting the conclusions reached in the IPSRA working
 group.
 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

Kelly & Ramamoorthi Informational [Page 5] RFC 3457 IPsec Remote Access Scenarios January 2003

 might also be termed "access control and authorization
 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.  In many instances, we cannot be certain 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.

Kelly & Ramamoorthi Informational [Page 6] RFC 3457 IPsec Remote Access Scenarios January 2003

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
 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.  That is, the IRAS in
 isolation may have some level of assurance that a particular device
 (the one in which the credential resides) is the one from which
 access is being attempted, but there is no explicit assurance
 regarding the identity of the user of the system.  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.

Kelly & Ramamoorthi Informational [Page 7] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 8] RFC 3457 IPsec Remote Access Scenarios January 2003

 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
 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 Remote Access 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 and accounting, but there are other mechanisms as
 well.  An ideal IPsec remote access solution might utilize the
 components of the underlying 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
       and accounting systems such as RADIUS

Kelly & Ramamoorthi Informational [Page 9] RFC 3457 IPsec Remote Access Scenarios January 2003

    o  should encourage migration from existing low-entropy
       password-based systems to more secure authentication systems
    o  if legacy user authentication 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
       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)

Kelly & Ramamoorthi Informational [Page 10] RFC 3457 IPsec Remote Access Scenarios January 2003

 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
  +------------------+                      |
  |  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

Kelly & Ramamoorthi Informational [Page 11] RFC 3457 IPsec Remote Access Scenarios January 2003

 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 target 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 IRAS protected network.
 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

Kelly & Ramamoorthi Informational [Page 12] RFC 3457 IPsec Remote Access Scenarios January 2003

 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,
 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 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

Kelly & Ramamoorthi Informational [Page 13] RFC 3457 IPsec Remote Access Scenarios January 2003

 o  extranet users using local corporate systems to access the remote
    company network of a business partner
 o  extranet users using their own system within another company's
    network to access their home corporate network
 o  extranet users using a business partner's system (located on that
    partner's network) to access their home corporate network
 o  remote users using a borrowed system (e.g., an airport kiosk) to
    access target network 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 target
 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 Informational [Page 14] RFC 3457 IPsec Remote Access Scenarios January 2003

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 corporate 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

Kelly & Ramamoorthi Informational [Page 15] RFC 3457 IPsec Remote Access Scenarios January 2003

 hardened,  the use of a time-variant credential is only effective if
 simultaneous access from more than one location is forbidden, and 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 of an unauthorized user who happens
 upon a connected but unattended systems.  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 Informational [Page 16] RFC 3457 IPsec Remote Access Scenarios January 2003

 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 an IP
 address from the target network.  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 target 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
 Internet-bound packets leaving the IRAC to first traverse the tunnel
 to the target network, where they may be subjected to target network
 policy.  A second approach which carries a bit less overhead entails
 modifying the IRAC's policy configuration to reflect that of the
 target network during the time the IRAC is connected.  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 Informational [Page 17] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 18] RFC 3457 IPsec Remote Access Scenarios January 2003

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

 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

Kelly & Ramamoorthi Informational [Page 19] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 20] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 21] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 22] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 23] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 24] RFC 3457 IPsec Remote Access Scenarios January 2003

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

Kelly & Ramamoorthi Informational [Page 25] RFC 3457 IPsec Remote Access Scenarios January 2003

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 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.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 be
 configured to pass IPsec protocols, then this must be accomplished
 prior to connection establishment.

Kelly & Ramamoorthi Informational [Page 26] RFC 3457 IPsec Remote Access Scenarios January 2003

3.5 Public System to Target Network

 This scenario entails a traveling user connecting to the target
 network using a public system owned by someone else.  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 publicly accessible system.  Note
 that a trust relationship between CORP-A and the owner of the public
 system may exist, but in many cases will not.

3.5.1 Authentication Requirements

 There are two variations to this scenario.  In the first, no trust
 relationship exists between the target network and 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 from such a system would seem to be ill-advised.
 If a one-time passphrase were used, this would mitigate the risk of
 passphrase capture by the public 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.
 However, many smartcards require a pin or passphrase to "unlock"
 them, which requires some level of trust in the kiosk 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 public
 system 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
 target.  However, the primary benefit of such a trust relationship
 would be derived from the ability to authenticate the machine from

Kelly & Ramamoorthi Informational [Page 27] RFC 3457 IPsec Remote Access Scenarios January 2003

 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 IRAC must possess some certifiable or secret knowledge of the
 IRAS prior to attempting to connect.  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.
    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.5.2 Device Configuration Requirements

 None.

3.5.3 Policy Configuration Requirements

 None.

Kelly & Ramamoorthi Informational [Page 28] RFC 3457 IPsec Remote Access Scenarios January 2003

3.5.4 Auditing Requirements

 The auditing requirements in this scenario are the same as for the
 telecommuter scenario.  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.5.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
 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 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.

Kelly & Ramamoorthi Informational [Page 29] RFC 3457 IPsec Remote Access Scenarios January 2003

5. Security Considerations

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

6. 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.
 [RADIUS]    Rigney, C., Rubens, A., Simpson, W. and S. Willens,
             "Remote Authentication Dial In User Service (RADIUS)",
             RFC 2865, June 2000.
 [IKE]       Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

7. Acknowledgements

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

8. Editors' Addresses

 Scott Kelly
 Airespace
 110 Nortech Pkwy
 San Jose CA 95134 USA
 Phone: +1 (408) 941-0500
 EMail: scott@hyperthought.com
 Sankar Ramamoorthi
 Juniper Networks
 1194 North Mathilda Ave
 Sunnyvale CA 94089-1206 USA
 Phone: +1 (408) 936-2630
 EMail: sankarr@juniper.net

Kelly & Ramamoorthi Informational [Page 30] RFC 3457 IPsec Remote Access Scenarios January 2003

9. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Kelly & Ramamoorthi Informational [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3457.txt · Last modified: 2003/01/27 18:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki