One document matched: draft-ietf-ipsra-reqmts-00.txt
IPsec Remote Access Working Group Scott Kelly, RedCreek
INTERNET-DRAFT Sankar Ramamoorthi, Netscreen
draft-ietf-ipsra-reqmts-00.txt March, 2000
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.
This document is a submission to the IETF IPsec remote access (IPSRA)
working group. Comments on this document should be sent to the IPSRA
discussion list (ietf-ipsra@vpnc.org).
Abstract
IPsec offers much promise as a secure remote access mechanism.
However, there are a significant number of 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 September, 2000 [Page 1]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4
1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4
1.3 General Terminology . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Device (Machine) Authentication . . . . . . . . . . . . . . . 7
2.1.2 User Authentication . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 User/Machine Authentication . . . . . . . . . . . . . . . . . 7
2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . . 7
2.1.5 Compatibility With Legacy Mechanisms . . . . . . . . . . . . . 8
2.2 Remote Host Configuration . . . . . . . . . . . . . . . . . . . 9
2.3 Security Policy Configuration . . . . . . . . . . . . . . . . . 10
2.4 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . . . . . 12
3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . . 13
3.1.2 Device Configuration Requirements . . . . . . . . . . . . . . 14
3.1.3 Policy Configuration Requirements . . . . . . . . . . . . . . 15
3.1.4 Mobility Requirements . . . . . . . . . . . . . . . . . . . . 16
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . . 16
3.2.1 Authentication Requirements . . . . . . . . . . . . . . . . . 17
3.2.2 Device Configuration Requirements . . . . . . . . . . . . . . 18
3.2.3 Policy Configuration Requirements . . . . . . . . . . . . . . 18
3.2.4 Mobility Requirements . . . . . . . . . . . . . . . . . . . . 18
3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . . . . . 18
3.3.1 Authentication Requirements . . . . . . . . . . . . . . . . . 19
3.3.2 Device Configuration Requirements . . . . . . . . . . . . . . 20
3.3.3 Policy Configuration Requirements . . . . . . . . . . . . . . 20
3.3.4 Mobility Requirements . . . . . . . . . . . . . . . . . . . . 20
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . . 21
3.4.1 Authentication Requirements . . . . . . . . . . . . . . . . . 21
3.4.2 Device Configuration Requirements . . . . . . . . . . . . . . 21
3.4.3 Policy Configuration Requirements . . . . . . . . . . . . . . 22
3.4.4 Mobility Requirements . . . . . . . . . . . . . . . . . . . . 22
3.5 Remote Dialup Laptop Access . . . . . . . . . . . . . . . . . . 22
3.6 Road Warrior to Corporate Network . . . . . . . . . . . . . . . 22
3.6.1 Authentication Requirements . . . . . . . . . . . . . . . . . 22
3.6.2 Device Configuration Requirements . . . . . . . . . . . . . . 23
3.6.3 Policy Configuration Requirements . . . . . . . . . . . . . . 23
3.6.4 Mobility Requirements . . . . . . . . . . . . . . . . . . . . 23
4. Scenario Commonalities . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 24
Kelly, Ramamoorthi Expires September, 2000 [Page 2]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
6. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 25
Kelly, Ramamoorthi Expires September, 2000 [Page 3]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
1. Introduction
In the recent past, remote access has typically consisted of dial-up
users accessing the corporate 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], TACACS, and others.
With the advent of IPsec, it has become possible to provide secure
remote access to corporate resources via the internet, as opposed to
via the PSTN alone. This has numerous benefits, financial and
otherwise, and presents strong incentives to migrate to an IPsec-
based remote access model. However, there are also numerous problems
to be solved in order to meet the functional requirements of remote
access users. 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 RADIUS,
PPP, PPTP, L2F, L2TP, and other remote access support protocols will
also be helpful, though not strictly necessary.
1.3 General Terminology
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 corporate network. An alternative term
is "Security Gateway".
o Security Gateway (SGW) - this refers to the device providing
access to the corporate network. An alternative term is IRAS.
o Virtual IP Address (VIP) - this term describes an address on
the local corporate subnet which is assigned to a remote
Kelly, Ramamoorthi Expires September, 2000 [Page 4]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
client, giving the appearance that the remote client resides
locally on the corporate 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.
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.
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, and mobility.
Following this are sections containing a requirements summary and
security considerations.
2. Overview
In a very general sense, all 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 access resources either
behind a SGW or on an IPsec protected host, and/or wishes to provide
other (specific) systems with 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
Kelly, Ramamoorthi Expires September, 2000 [Page 5]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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 remote access scenarios: endpoint authentication, remote
host configuration, and security policy are the most common of these,
while some scenarios also pose mobility requirements. Endpoint
authentication refers to verification of the identities of the
communication partners (e.g. the IRAC and the SGW). 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
configuration". Mobility refers to the remote client's ability to
acquire a new IP address while maintaining an active session, and may
apply to the ability to dynamically migrate between IRAS systems as
well. 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 host (identifiable
by its network address). IPsec offers mechanisms for this via AH or
ESP. Endpoint authentication within the IPsec context consists in
providing assurance that the endpoint is actually 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 for its effectiveness. This is due to the fact that 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 host
somehow, and then bind the IP address of this host to the trust
relationship established by the endpoint authentication process.
In the context of remote access, the authenticated entity may be a
machine, a user, 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 Expires September, 2000 [Page 6]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
2.1.1 Device (Machine) Authentication
In the case where no user input is required in order for the subject
device to access an authentication credential which is securely
stored upon that device, the entity authenticated by any of these
various mechanisms will be the device alone. That is, a shared secret
or a private key corresponding to a public key certificate may be
either stored on the device or contained in another device which is
securely accessible by the device (e.g. a smartcard). If a user is
not required to somehow "unlock" this credential prior to use, then
the knowledge required for its use is entirely contained within the
subject device.
In this case, the user has not been authenticated by the use of such
a credential; rather, the device has. In this case, the IRAS has some
level of assurance that a particular machine (the one to which the
credential was issued) is the one from which access is being
attempted, but no explicit assurance regarding the identity of the
user of the system.
2.1.2 User 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, then it is the user alone
which has been authenticated to some degree. That is, while there is
some assurance as to the user's network address, there is no
assurance as to the particular machine from which the user is
attempting access. This is because no machine/device credential is
employed in the authentication process.
2.1.3 User/Machine Authentication
In some cases, user input of some sort may be required to either
provide the client device with access to an authentication
credential, or to somehow modify the credential. That is, the
accurate application of the authentication credential requires
something which the user possesses or knows in tandem with something
which the system controls. For example, a private key may be
encrypted and stored either on the device or in a hardware token
which the user plugs into the device, and the user must provide a
password in order to decrypt it. In this case, assuming the
subsequent authentication operation succeeds, then both the user and
the user's system have been authenticated.
2.1.4 Remote Access Authentication
Kelly, Ramamoorthi Expires September, 2000 [Page 7]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
In the general case for remote access, authentication requirements
are typically asymmetric. From the IRAC's perspective, it is
important to ensure that the security gateway at the other end of the
connection is indeed the intended SGW, and not some rogue system
masquerading as the SGW. That is, the IRAC requires machine
authentication for the SGW. 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 it is difficult to imagine that user-level endpoint
authentication for the SGW might ever be required, the situation is
quite different for the IRAC. Here, it is often important to know
that the individual at the other end of the connection is one who is
authorized to access corporate resources, as opposed to someone who
happened upon an unoccupied but otherwise authorized system.
Authenticating the user is not quite so straightforward as
authenticating the user's machine. It typically requires some form of
user input, and often requires periodic renewal.
In situations where a high level of physical security does not exist,
it is common to require a user-input secret as part of
authentication, and then to periodically renew the authentication.
Choosing a renewal interval which provides an acceptable level of
risk, but which does not annoy the user too much, may be challenging.
It should be obvious that even this approach offers only limited
assurance in many cases.
Clearly, there are a number of assurance levels which are obtainable
with various endpoint authentication techniques. Also, there is a
good deal of variation in authentication requirements for differing
remote access scenarios. These are illustrated 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 underlying remote
access framework without modification. Inasmuch as this is possible,
this should be a goal. However, there may be cases where this simply
cannot be accomplished. 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
Kelly, Ramamoorthi Expires September, 2000 [Page 8]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
following goals:
o should provide direct support for legacy user authentication
systems such as RADIUS
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 point of entry should be provided in configurations
employing load-balancing and/or redundancy.
o must provide migration path to PKI-based mechanisms
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(s)
o Domain name(s)
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
Kelly, Ramamoorthi Expires September, 2000 [Page 9]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
o (others options)
Cases where such configuration is provided by the ISP are, for the
most Part, uninteresting for our purposes. 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 (local) corporate network:
corporate 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 internal corporate address is assigned to the
IRAC, and packets containing this assigned address are encapsulated,
with the outer headers containing the IRAC's routable address. This
provides the IRAC with a virtual presence on the corporate 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 corporate 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 corporate 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 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
Kelly, Ramamoorthi Expires September, 2000 [Page 10]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
connection to the corporate 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 client 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 corporate network, while we wish to restrict Bob's access to
specific segments. One way to accomplish this would be to statically
assign internal corporate "virtual" addresses to each, and then have
policies based upon these addresses, but this does not scale well,
due in part to the one-to-one mapping of virtual IP addresses.
A more scalable solution for remote client access control (or
authorization) would be to dynamically assign IP addresses. Such an
address could be assigned from a specific pool based upon the
authenticated endpoint identity, with access to specific resources
controlled by address-based policies in the SGW. Alternatively, an
arbitrary address could be assigned, 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 either case, the relevant security policy
configuration is specific to the security gateway, rather than to the
IRAC. It is these sorts of policy configuration which are encompassed
by this requirements category.
2.4 Mobility
IRAC mobility refers to the client's propensity to change its address
while maintaining a connection. For example, this could occur when
the DHCP lease for an ISP-assigned address expires, and a new
(different) address is allocated to the IRAC. This effectively
changes one of the tunnel endpoint addresses. Depending upon how such
address changes are handled (i.e is the tunnel dropped and re-
established, or maintained?), this capability may impose specific
requirements for remote access.
3. Scenarios
There are numerous remote access scenarios possible using IPsec. This
section contains a brief summary enumeration of these, followed by a
section 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 own home
systems to access corporate resources
Kelly, Ramamoorthi Expires September, 2000 [Page 11]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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
o extranet users using another company's system (on that
company's network) to access their home corporate network
o road warriors using their own laptop systems to access
corporate resources via an arbitrary ISP dialup connection
o roaming (e.g. wireless) users, using their own laptop
systems to access corporate resources
o remote users using someone else's system (e.g. an airport
kiosk) to access corporate resources
o remote user to remote user connections, in which both users
have a remote access connection to a common network
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. 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 +---+ |--| |
Kelly, Ramamoorthi Expires September, 2000 [Page 12]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
|IRAC |---|modem|------|ISP|==========|SGW|--| +----+
+-----+ +-----+ /---/ +---+ |
|
An alternative to this configuration entails placing a security
gateway between the IRAC and the modem. This is currently most common
in cases where DSL/CATV connections are used.
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 the 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 this is beyond the scope of
this document.
For the IRAC, the question arises as to whether machine
authentication may be acceptable under some circumstances, or whether
user authentication, either alone or in concert with machine
authentication, is required instead. In general, a system within a
user's home may be considered to be reasonably secure for purposes of
a typical short-lived remote access session. That is, under normal
circumstances, it is reasonable to believe that there are no
potential intruders lurking about, waiting for the user to leave the
PC momentarily unprotected. Likewise, it may be reasonable to believe
that insufficient incentive exists for someone to covertly enter the
user's home and compromise the user's credential.
On the other hand, and especially in the case of an always-on
connection, there is some likelihood that someone other than the
intended user may acquire access to the corporate network by virtue
of the fact that an active remote access session exists, and the
authorized user is not currently using it. This someone might be the
user's spouse, children, childrens' friend(s), housekeeper, or any of
a number of others. This tends to suggest that authentication should
be at the user level, and that it should be renewed relatively
frequently during active sessions.
To summarize, the following are the authentication requirements for
the IRAS and IRAC:
IRAS
----
o machine authentication MUST be provided.
Kelly, Ramamoorthi Expires September, 2000 [Page 13]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
IRAC
----
o support for either user or machine authentication MUST
be provided
o support for machine authentication MAY be provided
o support for user authentication SHOULD be provided
o support for a combination of user and machine authentication
MAY be provided
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 corporate 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 corporate 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
corporate network. For example, the virtual presence allows the
client to receive subnet broadcasts, which permits it to use WINS on
the corporate network. In addition, if the IRAC tunnels all traffic
to the corporate network, then the corporate 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 bits 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 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 SHOULD be supported
Kelly, Ramamoorthi Expires September, 2000 [Page 14]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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 by forcing all non-corporate packets leaving the IRAC to
first traverse the tunnel to the corporate network, where they may be
subjected to corporate policy.
A second approach which carries a bit less overhead entails modifying
the IRAC's policy configuration to reflect that of the corporation
during the time the IRAC is connected to the corporate network. In
this case, traffic is not forced to loop through the corporate site
prior to exiting to the internet or entering the IRAC. This requires
some sort of policy download capability as part of the SA
establishment process.
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 always 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 authentication 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 MUST be supported.
Kelly, Ramamoorthi Expires September, 2000 [Page 15]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
IRAC
----
o support for IRAS update of IRAC policy SHOULD be provided.
o if IRAS update of IRAC policy is not supported, IRAC MUST
support IRAS directives to "tunnel-all" and "block-all"
for non-tunneled traffic.
3.1.4 Mobility Requirements
It is possible, in the case where the IRAC's address is dynamically
provided by the ISP, that this address will change during a remote
access session. If this occurs, one of two things must also occur:
either the session must be dropped and re-established, or
mechanisms must exist for communicating the new address to the SGW,
and for modifying the SGW's outbound SA to reflect the new address.
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
Kelly, Ramamoorthi Expires September, 2000 [Page 16]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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 used, then SGW-A must provide some local mechanism for
authenticating USER, and further, SGW-B must trust this mechanism.
If access is permitted for anyone within corporation A, then
machine authentication might 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 MAY
be provided
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
Kelly, Ramamoorthi Expires September, 2000 [Page 17]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
MAY 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
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 (3) 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 Mobility Requirements
None.
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
Kelly, Ramamoorthi Expires September, 2000 [Page 18]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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
at least two 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. Since the laptop is in an
environment where unauthorized users might easily gain access, user-
level authentication is required. 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.
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 be supported
Kelly, Ramamoorthi Expires September, 2000 [Page 19]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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.
IRAC
----
o support for IRAS update of IRAC policy SHOULD be provided.
o if IRAS update of IRAC policy is not supported, IRAC MUST
support IRAS directives to "block-all" for non-tunneled
traffic.
3.3.4 Mobility Requirements
The mobility requirements in this scenario are the same as for the
telecommuter scenario, i.e. if the laptop has a dynamically
assigned CORP-B address which changes during the session with CORP-
A, the session must either be re-established, or a mechanism for
Kelly, Ramamoorthi Expires September, 2000 [Page 20]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
changing the associated session address must exist.
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 verify that the
connection is coming from one of CORP-A's systems by placing an
encrypted CORP-A credential on the laptop which requires a passphrase
to "unlock". In the desktop case 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 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
3.4.2 Device Configuration Requirements
Kelly, Ramamoorthi Expires September, 2000 [Page 21]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
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 Mobility Requirements
None, unless the desktop has a dynamically assigned address which
changes. If so, the requirements are the same as for the extranet
laptop.
3.5 Remote Dialup Laptop 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 Road Warrior to Corporate Network
This scenario entails a traveling user connecting back to the
corporate network using a 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 cannot trust a publically accessible system.
This being the case, it seems likely that access from such a
terminal would often be severely restricted, perhaps only
permitting access to a mail server.
3.6.1 Authentication Requirements
Given that a publically accessible machine cannot be trusted,
machine authentication of the remote system is out of the question.
Since such a system could easily capture and re-use a long-lived
passphrase, use of these would be ill advised. It seems that the
Kelly, Ramamoorthi Expires September, 2000 [Page 22]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
most secure remaining authentication mechanisms in this
circumstance would be to use either a smartcard, or a one-time
password.
IRAS
----
o machine authentication MUST be provided.
IRAC
----
o support for user authentication using one-time password
or hardware token SHOULD be provided
o if a passphrase is used, frequent renewal of user authentication
MUST occur to insure that an active session is not in use by
someone other than the intial user
3.6.2 Device Configuration Requirements
None.
3.6.3 Policy Configuration Requirements
None.
3.6.4 Mobility Requirements
None.
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 IRAC is required in all
scenarios
o A mechanism for providing device configuration for the
IRAC is useful in most scenarios. Such a mechanism must
be extensible.
o Machine authentication for the IRAS is generally only useful
when combined with user authentication, and such dual
authentication
Kelly, Ramamoorthi Expires September, 2000 [Page 23]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
is useful in some scenarios.
o Dynamic IRAS policy configuration is required in several
scenarios.
5. Security Considerations
[TBD]
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
Netscreen
2860 San Tomas Expwy
Santa Clara, CA 95051
E-mail: sramamoorthi@netscreen.com
Telephone: +1 (408) 330-7800
The IPSRA working group can be contacted via the IPSRA working
group's mailing list (ietf-ipsra@vpnc.org) or through its chairs:
Sara Bitan
sarab@radguard.com
Radguard
Paul Hoffman
paul.hoffman@vpnc.org
VPN Consortium
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 September, 2000 [Page 24]
Internet Draft <draft-ietf-ipsra-reqmts-00.txt> March, 2000
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens,
"Remote Authentication Dial In User Service
(RADIUS)", RFC2138
[SASL] Myers, J., "Simple Authentication and Security
Layer (SASL)", RFC 2222, October 1997.
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
8. Acknowledgements
The authors would like to acknowledge the many helpful comments of Sara
Bitan.
9. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Kelly, Ramamoorthi Expires September, 2000 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-21 07:50:41 |