< draft-ietf-ipsra-reqmts-03.txt   draft-ietf-ipsra-reqmts-04.txt >
IPsec Remote Access Working Group Scott Kelly, RedCreek IPsec Remote Access Working Group Scott Kelly, RedCreek
INTERNET-DRAFT Sankar Ramamoorthi, Nexsi INTERNET-DRAFT Sankar Ramamoorthi, Nexsi
draft-ietf-ipsra-reqmts-03.txt January, 2001 draft-ietf-ipsra-reqmts-04.txt August, 2001
Requirements for IPsec Remote Access Scenarios Requirements for IPsec Remote Access Scenarios
Status of This Memo Status of This Memo
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. Internet Drafts are all provisions of Section 10 of [RFC2026]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and working groups. Note that other groups may also distribute areas, and working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments on this document should be sent to the IETF IPsec remote Comments on this document should be sent to the IETF IPsec remote
access discussion list (ietf-ipsra@vpnc.org). access discussion list (ietf-ipsra@vpnc.org).
Abstract Abstract
IPsec offers much promise for securing remote access. However, there IPsec offers much promise as a secure remote access mechanism.
are a number of differing remote access scenarios, each having some However, there are a number of differing remote access scenarios,
shared and some unique requirements. A thorough understanding of each having some shared and some unique requirements. A thorough
these requirements is necessary in order to effectively evaluate the understanding of these requirements is necessary in order to
suitability of a specific set of mechanisms for any particular remote effectively evaluate the suitability of a specific set of mechanisms
access scenario. This document enumerates the requirements for a for any particular remote access scenario. This document enumerates
number of common remote access scenarios. the requirements for a number of common remote access scenarios.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . 9 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 10 1.3 General Terminology . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Machine-Level Authentication . . . . . . . . . . . . . . . . . 10 1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 User-Level Authentication . . . . . . . . . . . . . . . . . . 11 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Combined User/Machine Authentication . . . . . . . . . . . . . 11 2.1 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . . 12 2.1.1 Machine-Level Authentication . . . . . . . . . . . . . . . . . 7
2.1.5 Compatibility With Legacy Mechanisms . . . . . . . . . . . . . 13 2.1.2 User-Level Authentication . . . . . . . . . . . . . . . . . . 8
2.2 Remote Host Configuration . . . . . . . . . . . . . . . . . . . 14 2.1.3 Combined User/Machine Authentication . . . . . . . . . . . . . 8
2.3 Security Policy Configuration . . . . . . . . . . . . . . . . . 15 2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . . 9
2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.5 Compatibility With Legacy Remote Access Mechanisms . . . . . . 10
2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . . . . . 17 2.2 Remote Host Configuration . . . . . . . . . . . . . . . . . . . 11
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Security Policy Configuration . . . . . . . . . . . . . . . . . 12
3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . . . . . 18 2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . . 19 2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Device Configuration Requirements . . . . . . . . . . . . . . 20 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Policy Configuration Requirements . . . . . . . . . . . . . . 21 3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . . . . . 15
3.1.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 22 3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . . 16
3.1.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 22 3.1.2 Device Configuration Requirements . . . . . . . . . . . . . . 17
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . . 23 3.1.3 Policy Configuration Requirements . . . . . . . . . . . . . . 18
3.2.1 Authentication Requirements . . . . . . . . . . . . . . . . . 23 3.1.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Device Configuration Requirements . . . . . . . . . . . . . . 24 3.1.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 19
3.2.3 Policy Configuration Requirements . . . . . . . . . . . . . . 25 3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . . 20
3.2.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 25 3.2.1 Authentication Requirements . . . . . . . . . . . . . . . . . 21
3.2.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 25 3.2.2 Device Configuration Requirements . . . . . . . . . . . . . . 21
3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . . . . . 26 3.2.3 Policy Configuration Requirements . . . . . . . . . . . . . . 22
3.3.1 Authentication Requirements . . . . . . . . . . . . . . . . . 26 3.2.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Device Configuration Requirements . . . . . . . . . . . . . . 27 3.2.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 22
3.3.3 Policy Configuration Requirements . . . . . . . . . . . . . . 27 3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . . . . . 23
3.3.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 28 3.3.1 Authentication Requirements . . . . . . . . . . . . . . . . . 23
3.3.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 28 3.3.2 Device Configuration Requirements . . . . . . . . . . . . . . 24
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . . 29 3.3.3 Policy Configuration Requirements . . . . . . . . . . . . . . 24
3.4.1 Authentication Requirements . . . . . . . . . . . . . . . . . 29 3.3.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Device Configuration Requirements . . . . . . . . . . . . . . 30 3.3.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 25
3.4.3 Policy Configuration Requirements . . . . . . . . . . . . . . 30 3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . . 26
3.4.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 30 3.4.1 Authentication Requirements . . . . . . . . . . . . . . . . . 26
3.4.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 30 3.4.2 Device Configuration Requirements . . . . . . . . . . . . . . 27
3.5 Remote Dialup Laptop (Road Warrior) Access . . . . . . . . . . . 31 3.4.3 Policy Configuration Requirements . . . . . . . . . . . . . . 27
3.6 Third Party System to Target Network . . . . . . . . . . . . . . 31 3.4.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 27
3.6.1 Authentication Requirements . . . . . . . . . . . . . . . . . 31 3.4.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 27
3.6.2 Device Configuration Requirements . . . . . . . . . . . . . . 33 3.5 Public System to Target Network . . . . . . . . . . . . . . . . 28
3.6.3 Policy Configuration Requirements . . . . . . . . . . . . . . 33 3.5.1 Authentication Requirements . . . . . . . . . . . . . . . . . 28
3.6.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 33 3.5.2 Device Configuration Requirements . . . . . . . . . . . . . . 29
3.6.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 33 Table of Contents
Table of Contents, cont.
4. Scenario Commonalities . . . . . . . . . . . . . . . . . . . . . 33 3.5.3 Policy Configuration Requirements . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 34 3.5.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 30
6. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 3.5.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Scenario Commonalities . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 35 6. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A: Change Log . . . . . . . . . . . . . . . . . . . . . . . 36 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 32
Appendix A: Change Log . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Until recently, remote access has typically been characterized by Until recently, remote access has typically been characterized by
dial-up users accessing the target network via the Public Switched dial-up users accessing the target network via the Public Switched
Telephone Network (PSTN), with the dial-up connection terminating at Telephone Network (PSTN), with the dial-up connection terminating at
a Network Access Server (NAS) within the corporate domain. The a Network Access Server (NAS) within the target domain. The protocols
protocols facilitating this have usually been PPP-based, and access facilitating this have usually been PPP-based, and access control,
control, authorization, and accounting functions have typically been authorization, and accounting functions have typically been provided
provided using one or more of a number of available mechanisms, using one or more of a number of available mechanisms, including
including RADIUS [RADIUS]. Note that for such access, it has been RADIUS [RADIUS].
assumed that the communications infrastructure supporting the
connection (the PSTN) is relatively secure, and poses no threats to
communications integrity or confidentiality.
Such connections, while economical when the communicating parties are
within the same local exchange, become costly if the intervening
distance between parties requires a toll call. In response to this,
PPP-based tunneling mechanisms [L2TP, PPTP] have been developed to
provide remote access by allowing the user to first dial into a local
ISP account, and then tunnel an additional PPP connection over the
Internet into the target network. The developers of these mechanisms
have long recognized that vulnerabilities arise when data travels
over the public Internet, and have awaited the deployment of IPsec as
a response to these vulnerabilities.
Of the various tunneling mechanisms, the market seems to be settling
down around L2TP, but there are a number of pertinent issues with
respect to transit security within L2TP. In brief summary, these
include the following:
o weak tunnel endpoint authentication (shared secret only)
o no data stream integrity mechanism
o reliance upon PPP for encryption service
With respect to the first item above, while a certain level of tunnel
endpoint authentication is provided during L2TP tunnel establishment
(using a shared secret), it is possible for an observer to inject
traffic into the L2TP tunnel stream once this authentication step is
complete. It is also possible to modify the datastream, or to hijack
the tunnel. These are consequences of both the first and second
issues listed. Confidentiality also poses a significant challenge
for such tunneling mechanisms. Prior to IPsec deployment, L2TP has
been made to rely upon the encryption service provided by PPP. This
service is inadequate for many applications from a security
perspective, due in part to its reliance on manual configuration of
encryption keys, and also to the lack of a data stream integrity
mechanism during selection of the encryption protocol and keys.
It has been believed that IPsec would resolve these issues, given its
support for dynamic authenticated key exchange, data stream integrity
verification, and confidentiality. Indeed, the increasing
availability of IPsec renders it possible to provide more secure
remote access to resources via the Internet than has been available
in the past. Given this, and the fact that L2TP and related protocols
have been refined over the years to meet the needs of the remote
access community, it seems appropriate to ask if L2TP combined with
IPsec would provide an acceptable and even highly desirable solution
to the problem of secure remote access. The answer is that while
combining L2TP and IPsec may be a sufficient solution for some remote
acess deployments, it is not a universal remote access solution, due
to a number of inherent security issues.
When combining IPsec and L2TP, a number of security issues must be
addressed. These points are summarized in the following list, and
then discussed in further detail below:
o the transit selectors become opaque to the IPsec implementation,
meaning tunnel membership must be enforced within the L2TP
implementation
o user-level authentication does not occur until an IPsec SA has
been established
o the most common user-level authentication mechanism employed
within L2TP (RADIUS), has known security issues
o the increased complexity resulting from combining L2TP/IPsec
implementations significantly increases the likelihood of
introducing a security-compromising bug
The first issue pertains to where tunnel membership is enforced.
IPsec is designed to provide tunnel membership enforcement with
regard to transit traffic. However, when combining L2TP and IPsec,
the only transit selectors visible to the IPsec implementation are
the outer IP and encapsulating UDP headers. Hence, the L2TP
implementation must enforce tunnel membership, ensuring that packets
emerging from a given L2TP tunnel have the appropriate source and
destination addresses in accordance with the instantiated security
policy.
The second L2TP/IPsec issue pertains to the manner in which user
authentication is accomplished. That is, the secure (IPsec) channel
must be established first, with user authentication following within
L2TP. This means that the security gateway terminating the remote
access connection must either accept some weak form of authentication
(e.g. a universal preshared key), or use public-key-based
authentication. If a universal preshared key is used, this has
obvious security implications, as such a key may be compromised in
numerous ways. In such cases, the SGW can be made to expend a great
deal of resources engaging in spurious key exchange calculations, or
perhaps worse, a compromised key may be used to open a conduit to the
underlying user authentication mechanism, through which other attacks
may be launched.
The best way to mitigate these vulnerabilities is to use reliable
PKI-based mechanisms to authenticate the initial connection. This
requires that a private key (with a corresponding public key
certificate) be made available to the user's system, and that the
user's system be capable of verifying a public key certificate
presented by the security gateway granting access to the target
network. Some have suggested providing a relatively long-lived
certificate which binds a keypair to a particular system (rather than
a user), and using this to authenticate the initial connection. This
is effective if and only if the private key is adequately secured
during distribution, storage and use, and this is very difficult to
achieve given the open nature of commonly-used commercial operating
systems. It is likely not achievable unless the private key is
stored and used within a secure container of some sort (e.g. a
tamper-resistant smartcard), this container cannot be easily moved to
another system, and the system cannot easily be appropriated and used
by someone without authorization.
If such a secure containment mechanism cannot be provided, (e.g. a
private key is instead stored on the local hard drive and this is
used to authenticate the system), then additional security issues
certainly exist. Such keys may be compromised in numerous ways, and
such compromises may go undetected indefinitely. Similar issues exist
if the system is vulnerable to either theft or unauthorized use. In
all cases, the end result is very similar to that of the universal
preshared key, in that once an attacker has a valid private key,
attacks upon the underlying user authentication mechanism are
possible, as well as DoS attacks. Hence, to mitigate the associated
risks, such keys must be relatively short-lived. This implies a need
for a secure mechanism for periodically refreshing such credentials,
with the associated refresh interval being adjustable according to
the desired level of assurance.
Assuming we choose to use L2TP/IPsec, that the user's system is
protected from theft and unauthorized use, and that an acceptably
secure PKI-based authentication mechanism is employed for creating
the IPsec channel which does not include user-level authentication, a
second security issue arises. The user is now expected to
authenticate by providing a username and password. In most current
deployments, the L2TP tunnel termination point must provide this
information to a RADIUS server, and permit or deny access based upon
the server's response. If the RADIUS server does not co-reside with
the L2TP implementation, there are a number of well-known security
issues with the ensuing online RADIUS conversation. If the target
network upon which this RADIUS conversation occurs is not completely
trusted, and the conversation between the SGW and the RADIUS server
is not secured (e.g. using IPsec), then it is possible that the
username and password may be compromised. Note that this must be
considered regardless of whether L2TP is used, if legacy mechanisms
such as RADIUS require support.
Note that if the username and password are used prior to tunnel Note that for such access, it has often been assumed that the
establishment in order to obtain a short-lived public key communications infrastructure supporting the ISP connection (the
certificate, the L2TP authentication mechanism becomes somewhat PSTN) is relatively secure, and poses no significant threats to
superfluous. On the other hand, if the user identity is not bound to communications integrity or confidentiality. Based on this
the IPsec authentication credential, and the credential is not stored assumption, connection security has been limited to access control at
in a theft and tamper resistant container within which it is used, the NAS based on username/passphrase pairs. In reality, PSTN dialup
numerous attacks become possible. While such risks may be acceptable connections have never been impervious to a determined adversary.
for some installations, they will not be in others. As always,
mechanisms which provide for a gradation of assurance levels
according to need are most useful, and derivation of such mechanisms
should be the aim of a secure remote access design effort.
The third issue in combining L2TP and IPsec listed above relates to The availability of widespread broadband access, in concert with the
the increased complexity resulting both from adding the additional desire to reduce the cost of PSTN toll access, have driven the
L2TP layer, and from the resulting interactions between the layers. development of Internet-based remote access mechanisms. In some
This is by far the most difficult of the three issues to quantify, cases, PPP-based tunneling mechanisms have been used to provide
though current experience with such systems indicates that the number remote access by allowing the dial user to first access a local ISP
of software bugs which are not identified in the test phase increases account, and then tunnel an additional PPP connection over the
with code complexity. Hence, if the security requirements of a given Internet into the target network. In the case of broadband users,
remote access scenario call for a high assurance system, this such connections are tunneled directly over the Internet. While these
interaction must be taken into account in selecting the remote access mechanisms have been lacking in terms of security features, the
mechanism. 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 Remote access via the Internet has numerous benefits, financial and
otherwise. However, security is paramount, and this presents strong otherwise. However, security is paramount, and this presents strong
incentives for migration from the old dial-up model to a more secure incentives for migration from the old dial-up model to a more secure
IPsec-based remote access model. Meeting the security requirements of IPsec-based remote access model. Meeting the security requirements of
various classes of remote access users presents a number of various classes of remote access users presents a number of
challenges. It is the aim of this document to explore and enumerate challenges. It is the aim of this document to explore and enumerate
the requirements of various IPsec remote access scenarios, without the requirements of various IPsec remote access scenarios, without
suggesting particular solutions for them. suggesting particular solutions for them.
skipping to change at page 8, line 35 skipping to change at page 5, line 34
o IPsec Remote Access Client (IRAC)- this term is used to refer to o IPsec Remote Access Client (IRAC)- this term is used to refer to
the remote access user's system. the remote access user's system.
o IPsec Remote Access Server (IRAS) - this term refers to the device o IPsec Remote Access Server (IRAS) - this term refers to the device
providing access to the target network. An alternative term providing access to the target network. An alternative term
is "Security Gateway". is "Security Gateway".
o Security GateWay (SGW) - this refers to the device providing o Security GateWay (SGW) - this refers to the device providing
access to the target network. An alternative term is IRAS. access to the target network. An alternative term is IRAS.
o Virtual IP address (VIP) - this term describes an address on o Virtual IP address (VIP) - this term describes an address from
the local subnet which is assigned to a remote client, a subnet local to the target network which is assigned to a
giving the appearance that the remote client resides on remote client, giving the appearance that the remote client
a local subnet. actually resides on the target network.
o Machine-Level Authentication - this term describes the o Machine-Level Authentication - this term describes the
case where the identity of a machine is verified by virtue case where the identity of a machine is verified by virtue
of the machine's possession and application of some of the machine's possession and application of some
combination of authenticators. For a more complete definition, combination of authenticators. For a more complete definition,
see section 2. see section 2.
o User-Level Authentication - this term describes the case o User-Level Authentication - this term describes the case
where the identity of a user (as opposed to that of a machine) where the identity of a user (as opposed to that of a machine)
is verified by virtue of the user's possession and application is verified by virtue of the user's possession and application
of some combination of authenticators. For a more complete of some combination of authenticators. For a more complete
definition, see section 2. definition, see section 2.
o NAPT - Network Address/Port Translation
1.4 Document Organization 1.4 Document Organization
The balance of this document is organized as follows: First, there is The balance of this document is organized as follows: First, there is
a general overview of the basic requirements categories, including a general overview of the basic requirements categories, including
definitions relevant to these categories. Following this is a section definitions relevant to these categories. Following this is a section
devoted to each remote access scenario. Within each of these sections devoted to each remote access scenario. Within each of these sections
there are subsections detailing requirements specific to that there are subsections detailing requirements specific to that
scenario in each of the following areas: endpoint authentication, scenario in each of the following areas: endpoint authentication,
remote host configuration, policy configuration, auditing, and remote host configuration, policy configuration, auditing, and
intermediary traversal. intermediary traversal.
2. Overview 2. Overview
In a very general sense, all secure remote access scenarios have a In a very general sense, all secure remote access scenarios have a
similar high-level appearance: similar high-level appearance:
target network target network
| |
| +---+ | +---+
+-------------+ +-----------+ |---| | +-------------+ +-----------+ |---| |
|remote access| internet | security | | +---+ |remote access| Internet | security | | +---+
| client |=============| gateway |--| | client |=============| gateway |--|
| (IRAC) | |(SGW/IRAS) | | +---+ | (IRAC) | |(SGW/IRAS) | | +---+
+-------------+ +-----------+ |---| | +-------------+ +-----------+ |---| |
| +---+ | +---+
In all cases, a remote client wishes to securely access resources 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 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 provide other (specific) systems with secure access to the client's
own resources. There are numerous details which may differ, depending own resources. There are numerous details which may differ, depending
on the particular scenario. For example, the IRAC may be within on the particular scenario. For example, the IRAC may be within
skipping to change at page 10, line 27 skipping to change at page 7, line 27
authentication in the IPsec context consists in providing assurance authentication in the IPsec context consists in providing assurance
that a network packet originates from a specific endpoint, typically that a network packet originates from a specific endpoint, typically
a user, host, or application. IPsec offers mechanisms for this via AH a user, host, or application. IPsec offers mechanisms for this via AH
or ESP. End user authentication within the IPsec context consists in or ESP. End user authentication within the IPsec context consists in
providing assurance that the endpoint is what or who it claims to be. providing assurance that the endpoint is what or who it claims to be.
IPsec currently offers mechanisms for this as part of IKE [IKE]. IPsec currently offers mechanisms for this as part of IKE [IKE].
While the two types of authentication differ, they are not unrelated. While the two types of authentication differ, they are not unrelated.
In fact, data source authentication relies upon endpoint In fact, data source authentication relies upon endpoint
authentication, because it is possible to inject packets with a authentication, because it is possible to inject packets with a
particular IP address into the internet from many arbitrary particular IP address into the Internet from many arbitrary
locations, so that we cannot be certain in many instances that a locations, so that we cannot be certain in many instances that a
packet actually originates from a particular host, or even from the packet actually originates from a particular host, or even from the
network upon which that host resides. To resolve this, one must network upon which that host resides. To resolve this, one must
first authenticate the particular endpoint somehow, and then bind the first authenticate the particular endpoint somehow, and then bind the
addressing information (e.g. IP address, protocol, port) of this addressing information (e.g. IP address, protocol, port) of this
endpoint into the trust relationship established by the endpoint into the trust relationship established by the
authentication process. authentication process.
In the context of secure remote access, the authenticated entity may In the context of secure remote access, the authenticated entity may
be a machine, a user (application), or both. The authentication be a machine, a user (application), or both. The authentication
skipping to change at page 11, line 21 skipping to change at page 8, line 21
then it is problematic to state that such credential usage then it is problematic to state that such credential usage
authenticates anything other than the subject device. authenticates anything other than the subject device.
In some cases, a user may be required to satisfy certain criteria In some cases, a user may be required to satisfy certain criteria
prior to being given access to stored credentials. In such cases, the prior to being given access to stored credentials. In such cases, the
level of user authentication provided by the use of such credentials level of user authentication provided by the use of such credentials
is somewhat difficult to derive. If sufficiently strong access is somewhat difficult to derive. If sufficiently strong access
controls exist for the system housing the credential, then there may controls exist for the system housing the credential, then there may
be a strong binding between the authorized system user and the be a strong binding between the authorized system user and the
credential. However, at the time the credential is presented, the credential. However, at the time the credential is presented, the
IRAS itself has no such assurance. In order for the IRAS to derive IRAS itself has no such assurance. That is, the IRAS in isolation may
additional assurance regarding the user identity, an additional user have some level of assurance that a particular device (the one in
credential of some sort would be required. This is discussed further which the credential resides) is the one from which access is being
below. 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 2.1.2 User-Level Authentication
In some cases, the user may possess an authentication token In some cases, the user may possess an authentication token
(preshared key, private key, passphrase, etc.), and may provide this (preshared key, private key, passphrase, etc.), and may provide this
or some derivative of this whenever authentication is required. If or some derivative of this whenever authentication is required. If
this token or derivative is delivered directly to the other endpoint this token or derivative is delivered directly to the other endpoint
without modification by the IRAC system, and if the IRAC system without modification by the IRAC system, and if the IRAC system
provides no further credentials of its own, then it is the user alone provides no further credentials of its own, then it is the user alone
which has been authenticated. That is, while there may be some which has been authenticated. That is, while there may be some
skipping to change at page 12, line 10 skipping to change at page 9, line 13
independently of the stored credential. In the case where the independently of the stored credential. In the case where the
passphrase is applied to the credential prior to use, the level of passphrase is applied to the credential prior to use, the level of
assurance derived from successful application of the credential assurance derived from successful application of the credential
varies according to your viewpoint. varies according to your viewpoint.
From the perspective of a system consisting of user, IRAC, IRAS, and From the perspective of a system consisting of user, IRAC, IRAS, and
a collection of system protections and security procedures, it may be a collection of system protections and security procedures, it may be
said that the user has been authenticated to an extent which depends said that the user has been authenticated to an extent which depends
upon the strength of the security procedures and system protections upon the strength of the security procedures and system protections
which are in place. However, from the perspective of the IRAS alone, which are in place. However, from the perspective of the IRAS alone,
there is no assurance with respect to user identity. That is, schemes there is little assurance with respect to user identity. That is,
requiring that stored credentials be modified by user input prior to schemes requiring that stored credentials be modified by user input
use may only be said to provide user-level authentication within the prior to use may only be said to provide user-level authentication
context of the larger system, and then, the level of assurance within the context of the larger system, and then, the level of
derived is directly proportional to the weakest security attribute of assurance derived is directly proportional to the weakest security
the entire system. attribute of the entire system.
When considering remote access from a general perspective, When considering remote access from a general perspective,
assumptions regarding the overall system are liable to prove assumptions regarding the overall system are liable to prove
incorrect. This is because the IRAS and the IRAC may not be within 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 the same domain of control; extranet scenarios are a good example of
this. Hence, the most desirable joint user/machine authentication this. Hence, the most desirable joint user/machine authentication
mechanisms in this context are those which provide a high level of mechanisms in this context are those which provide a high level of
assurance to both the IRAS and the IRAC, independently of the larger assurance to both the IRAS and the IRAC, independently of the larger
system of which the user, IRAS, and IRAC are a part. system of which the user, IRAS, and IRAC are a part.
skipping to change at page 13, line 22 skipping to change at page 10, line 26
Clearly, there are variable assurance levels which are attainable Clearly, there are variable assurance levels which are attainable
with the various endpoint authentication techniques, and none of the with the various endpoint authentication techniques, and none of the
techniques discussed offer absolute assurance. Also, there are techniques discussed offer absolute assurance. Also, there are
variations in the authentication requirements among different remote variations in the authentication requirements among different remote
access scenarios. This means there is no "cookie cutter" solution for access scenarios. This means there is no "cookie cutter" solution for
this problem, and that individual scenarios must be carefully this problem, and that individual scenarios must be carefully
examined in order to derive specific requirements for each. These are examined in order to derive specific requirements for each. These are
examined on a case by case basis below in the detailed scenario examined on a case by case basis below in the detailed scenario
descriptions. descriptions.
2.1.5 Compatibility With Legacy Mechanisms 2.1.5 Compatibility With Legacy Remote Access Mechanisms
There are a number of currently deployed remote access mechanisms There are a number of currently deployed remote access mechanisms
which were installed prior to the deployment of IPsec. Typically, which were installed prior to the deployment of IPsec. Typically,
these are dialup systems which rely upon RADIUS for user these are dialup systems which rely upon RADIUS for user
authentication, but there are other mechanisms as well. An ideal authentication and accounting, but there are other mechanisms as
IPsec remote access solution might utilize the components of the well. An ideal IPsec remote access solution might utilize the
underlying user authentication framework without modification. components of the underlying framework without modification. Inasmuch
Inasmuch as this is possible, this should be a goal. However, there as this is possible, this should be a goal. However, there may be
may be cases where this simply cannot be accomplished, due to cases where this simply cannot be accomplished, due to security
security and/or other considerations. In such cases, the IPsec remote and/or other considerations. In such cases, the IPsec remote access
access framework should be designed to accommodate migration from framework should be designed to accommodate migration from these
these mechanisms as painlessly as is possible. mechanisms as painlessly as is possible.
In general, proposed IPsec remote access mechanisms should meet the In general, proposed IPsec remote access mechanisms should meet the
following goals: following goals:
o should provide direct support for legacy user authentication o should provide direct support for legacy user authentication
systems such as RADIUS and accounting systems such as RADIUS
o should encourage migration from existing low-entropy o should encourage migration from existing low-entropy
password-based systems to more secure authentication systems password-based systems to more secure authentication systems
o if legacy support cannot be provided without some sort of o if legacy user authentication support cannot be provided without
migration, the impact of such migration should be minimized some sort of migration, the impact of such migration should be
minimized
o user authentication information must be protected against o user authentication information must be protected against
eavesdropping and replay (including the user identity) eavesdropping and replay (including the user identity)
o single sign-on capability should be provided in configurations o single sign-on capability should be provided in configurations
employing load-balancing and/or redundancy employing load-balancing and/or redundancy
o n-factor authentication mechanisms should be supported o n-factor authentication mechanisms should be supported
2.2 Remote Host Configuration 2.2 Remote Host Configuration
skipping to change at page 15, line 38 skipping to change at page 12, line 42
configured host which physically resides upon the target network configured host which physically resides upon the target network
would. It is this sort of configuration with which this requirements would. It is this sort of configuration with which this requirements
category is concerned. category is concerned.
2.3 Security Policy Configuration 2.3 Security Policy Configuration
Security policy configuration refers to IPsec access policies for Security policy configuration refers to IPsec access policies for
both the remote access client and the security gateway. It may be both the remote access client and the security gateway. It may be
desirable to configure access policies on connecting IRAC systems desirable to configure access policies on connecting IRAC systems
which will protect the target network. For example, since a client which will protect the target network. For example, since a client
has access to the internet (via its routable address), other systems has access to the Internet (via its routable address), other systems
on the internet also have some level of reciprocal access to the on the Internet also have some level of reciprocal access to the
client. In some cases, it may be desirable to block this internet 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 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 a tunneled connection to the target network. This is a matter of
client security policy configuration. client security policy configuration.
For the security gateway, it may also be desirable to dynamically For the security gateway, it may also be desirable to dynamically
adjust policies based upon the user with which a connection has been adjust policies based upon the user with which a connection has been
established. For example, say there are two remote users, named Alice established. For example, say there are two remote users, named Alice
and Bob. We wish to provide Alice with unrestricted access to the and Bob. We wish to provide Alice with unrestricted access to the
corporate network, while we wish to restrict Bob's access to specific target network, while we wish to restrict Bob's access to specific
segments. One way to accomplish this would be to statically assign segments. One way to accomplish this would be to statically assign
internal "virtual" addresses to each user in a one-to-one mapping, so 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 that each user always has the same address. Then, a particular user's
access could be controlled via policies based upon the particular access could be controlled via policies based upon the particular
address. However, this does not scale well. address. However, this does not scale well.
A more scalable solution for remote client access control would be to A more scalable solution for remote client access control would be to
dynamically assign IP addresses from a specific pool based upon the dynamically assign IP addresses from a specific pool based upon the
authenticated endpoint identity, with access to specific resources authenticated endpoint identity, with access to specific resources
controlled by address-based policies in the SGW. This is very similar controlled by address-based policies in the SGW. This is very similar
skipping to change at page 17, line 45 skipping to change at page 14, line 49
There are numerous remote access scenarios possible using IPsec. This There are numerous remote access scenarios possible using IPsec. This
section contains a brief summary enumeration of these, followed by a section contains a brief summary enumeration of these, followed by a
subsection devoted to each which explores the various requirements in subsection devoted to each which explores the various requirements in
terms of the categories defined above. terms of the categories defined above.
The following scenarios are discussed: The following scenarios are discussed:
o dialup/dsl/cablemodem telecommuters using their o dialup/dsl/cablemodem telecommuters using their
systems to access remote resources systems to access remote resources
o extranet users using their corporate desktop systems to o extranet users using local corporate systems to
access the remote company network of a business partner access the remote company network of a business partner
o extranet users using their own laptop within another o extranet users using their own system within another
company's network to access their home corporate network company's network to access their home corporate network
o extranet users using a business partner's system (on that o extranet users using a business partner's system (located
partner's network) to access their home corporate network on that partner's network) to access their home corporate
network
o road warriors using laptop systems to access target
resources via an arbitrary ISP dialup connection
o remote users using a borrowed system (e.g. an airport o remote users using a borrowed system (e.g. an airport
kiosk) to access corporate resources kiosk) to access target network resources
3.1 Telecommuters (Dialup/DSL/Cablemodem) 3.1 Telecommuters (Dialup/DSL/Cablemodem)
The telecommuter scenario is one of the more common remote access The telecommuter scenario is one of the more common remote access
scenarios. The convenience and wide availability of internet access scenarios. The convenience and wide availability of Internet access
makes this an attractive option under many circumstances. Users may makes this an attractive option under many circumstances. Users may
access the internet from the comfort of their homes or hotel rooms, access the Internet from the comfort of their homes or hotel rooms,
and using this internet connection, access the resources of a and using this Internet connection, access the resources of a target
corporate network. In some cases, dialup accounts are used to provide network. In some cases, dialup accounts are used to provide the
the initial internet access, while in others some type of "always-on" initial Internet access, while in others some type of "always-on"
connection such as a DSL or CATV modem is used. connection such as a DSL or CATV modem is used.
The dialup and always-on cases are very similar, with two significant The dialup and always-on cases are very similar, with two significant
differences: address assignment mechanism, and connection duration. differences: address assignment mechanism, and connection duration.
In most dialup cases, the IRAC's IP address is dynamically assigned In most dialup cases, the IRAC's IP address is dynamically assigned
as part of connection setup, and with fairly high likelihood, it is as part of connection setup, and with fairly high likelihood, it is
different each time the IRAC connects. DSL/CATV users, on the other different each time the IRAC connects. DSL/CATV users, on the other
hand, often have static IP addresses assigned to them, although hand, often have static IP addresses assigned to them, although
dynamic assignment is on the increase. As for connection duration, dynamic assignment is on the increase. As for connection duration,
dialup remote access connections are typically short-lived, while dialup remote access connections are typically short-lived, while
always-on connections may maintain remote access connections for always-on connections may maintain remote access connections for
significantly longer periods of time. significantly longer periods of time.
The general configuration in either case looks like this: The general configuration in either case looks like this:
corporate net corporate net
| +----+ | +----+
+-----+ +-----+ /---/ internet +---+ |--| | +-----+ +-----+ /---/ Internet +---+ |--| |
|IRAC |---|modem|------|ISP|==========|SGW|--| +----+ |IRAC |---|modem|------|ISP|==========|SGW|--| +----+
+-----+ +-----+ /---/ +---+ | +-----+ +-----+ /---/ +---+ |
| |
An alternative to this configuration entails placing a security An alternative to this configuration entails placing a security
gateway between the user's system and the modem, in which case this 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 added SGW becomes the IRAC. This is currently most common in cases
where DSL/CATV connections are used. where DSL/CATV connections are used.
3.1.1 Endpoint Authentication Requirements 3.1.1 Endpoint Authentication Requirements
The authentication requirements of this scenario depend in part upon The authentication requirements of this scenario depend in part upon
the general security requirements of the network to which access is the general security requirements of the network to which access is
to be provided. Assuming that the target SGW is physically secure, to be provided. Assuming that the corporate SGW is physically secure,
machine authentication for the SGW is sufficient. If this assumption machine authentication for the SGW is sufficient. If this assumption
regarding physical security is incorrect, it is not clear that regarding physical security is incorrect, it is not clear that
stronger authentication for the SGW could be guaranteed, and stronger authentication for the SGW could be guaranteed, and
derivation of an effective mechanism for that case is beyond the derivation of an effective mechanism for that case is beyond the
scope of this document. scope of this document.
For the IRAC, there are numerous threats to the integrity of the user For the IRAC, there are numerous threats to the integrity of the user
authentication process. Due to the open nature of common consumer authentication process. Due to the open nature of common consumer
operating systems, some of these threats are quite difficult to operating systems, some of these threats are quite difficult to
protect against. For example, it is very difficult to assert with any protect against. For example, it is very difficult to assert with any
level of certainty that a single user system which permits the level of certainty that a single user system which permits the
downloading and running of arbitrary applications from the internet downloading and running of arbitrary applications from the Internet
has not been compromised, and that a covert application is not has not been compromised, and that a covert application is not
monitoring and interacting with the user's data at any point in time. monitoring and interacting with the user's data at any point in time.
However, there are 2 general threats we might realistically hope to However, there are 2 general threats we might realistically hope to
somehow mitigate with appropriate authentication mechanisms if we can somehow mitigate with appropriate authentication mechanisms if we can
assume that the system has not been compromised in this manner. assume that the system has not been compromised in this manner.
First, there is the possibility that a secure connection is First, there is the possibility that a secure connection is
established for a particular user, but that someone other than the established for a particular user, but that someone other than the
intended user is currently using that connection. Second, there is intended user is currently using that connection. Second, there is
the possibility that the user's credential (password, hardware token, the possibility that the user's credential (password, hardware token,
skipping to change at page 20, line 4 skipping to change at page 17, line 4
require periodic application of a time-variant credential. require periodic application of a time-variant credential.
Mitigation of the second threat, credential compromise, is difficult, Mitigation of the second threat, credential compromise, is difficult,
and depends upon a number of factors. If the IRAC system is running a and depends upon a number of factors. If the IRAC system is running a
highly secure operating system, then a time-variant credential may highly secure operating system, then a time-variant credential may
again offer some value. A static password is clearly deficient in again offer some value. A static password is clearly deficient in
this scenario, since it may be subject to either online or offline this scenario, since it may be subject to either online or offline
guessing, and eventually compromised - which is the threat we are guessing, and eventually compromised - which is the threat we are
attempting to mitigate. However, if the IRAC operating system is not attempting to mitigate. However, if the IRAC operating system is not
hardened, the use of a time-variant credential is only effective if hardened, the use of a time-variant credential is only effective if
simultaneous access from more than one location is forbidden, if the simultaneous access from more than one location is forbidden, and if
credential generation mechanism is not easily compromised. the credential generation mechanism is not easily compromised.
A second approach to the credential compromise problem entails using A second approach to the credential compromise problem entails using
a PKI-based credential which is stored within a secure container of a PKI-based credential which is stored within a secure container of
some sort, and which requires some user interaction prior to some sort, and which requires some user interaction prior to
operation (e.g. a smartcard). If such a credential requires periodic operation (e.g. a smartcard). If such a credential requires periodic
user interaction to continue operating (e.g. pin re-entry), this may user interaction to continue operating (e.g. pin re-entry), this may
help to limit the access an unauthorized user who happens upon a help to limit the access of an unauthorized user who happens upon a
connected but unattended system realizes. However, choosing an connected but unattended systems. However, choosing an acceptable
acceptable refresh interval is a difficult problem, and if the pin is refresh interval is a difficult problem, and if the pin is not time-
not time-variant, this provides limited additional assurance. variant, this provides limited additional assurance.
To summarize, the following are the authentication requirements for To summarize, the following are the authentication requirements for
the IRAS and IRAC: the IRAS and IRAC:
IRAS IRAS
---- ----
o machine authentication MUST be provided. o machine authentication MUST be provided.
IRAC IRAC
skipping to change at page 21, line 7 skipping to change at page 18, line 7
system, or the telecommuter's system is assigned a virtual address system, or the telecommuter's system is assigned a virtual address
from within the target address space. In the first case, there are no from within the target address space. In the first case, there are no
device configuration requirements which are not already satisfied by device configuration requirements which are not already satisfied by
the ISP. However, this case is the exception, rather than the rule. the ISP. However, this case is the exception, rather than the rule.
The second case is far more common, due to the numerous benefits The second case is far more common, due to the numerous benefits
derived by providing the IRAC with a virtual presence on the target derived by providing the IRAC with a virtual presence on the target
network. For example, the virtual presence allows the client to network. For example, the virtual presence allows the client to
receive subnet broadcasts, which permits it to use WINS on the target 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. In addition, if the IRAC tunnels all traffic to the target
network, then the target policy can be applied to internet traffic network, then the target policy can be applied to Internet traffic
to/from the IRAC. to/from the IRAC.
In this case, the IRAC requires, at minimum, assignment of a In this case, the IRAC requires, at minimum, assignment of an IP
corporate IP address. Typically, the IRAC requires anywhere from address from the target network. Typically, the IRAC requires
several more to many more elements of configuration information, anywhere from several more to many more elements of configuration
depending upon the corporate network's level of topological information, depending upon the corporate network's level of
complexity. For a fairly complete list, see section 2.2. topological complexity. For a fairly complete list, see section 2.2.
To summarize, the following are the device configuration requirements To summarize, the following are the device configuration requirements
for the IRAC: for the IRAC:
o support for a virtual IP (VIP) address MAY be provided o support for a virtual IP (VIP) address MAY be provided
o if VIP support is provided, support for all device-related o if VIP support is provided, support for all device-related
parameters listed in section 2.2 above SHOULD be provided parameters listed in section 2.2 above SHOULD be provided
o support for address assignment based upon authenticated o support for address assignment based upon authenticated
identity MAY be provided identity MAY be provided
o if authenticated address assignment is not supported, an o if authenticated address assignment is not supported, an
identity-based dynamic policy update mechanism such as identity-based dynamic policy update mechanism such as
is described in [ARCH] MUST be supported. is described in [ARCH] MUST be supported.
3.1.3 Policy Configuration Requirements 3.1.3 Policy Configuration Requirements
In terms of IRAC policy configuration, the most important issue In terms of IRAC policy configuration, the most important issue
pertains to whether the IRAC has direct internet access enabled (for pertains to whether the IRAC has direct Internet access enabled (for
browsing, etc.) while a connection to the corporate network exists. browsing, etc.) while a connection to the target network exists.
This is important since the fact that the IRAC has access to sites on 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 the Internet implies that those sites have some level of reciprocal
access to the IRAC. It may be desirable to completely eliminate this access to the IRAC. It may be desirable to completely eliminate this
type of access while a tunnel is active. type of access while a tunnel is active.
Alternatively, the risks may be mitigated somewhat by forcing all Alternatively, the risks may be mitigated somewhat by forcing all
non-vpn packets leaving the IRAC to first traverse the tunnel to the Internet-bound packets leaving the IRAC to first traverse the tunnel
target network, where they may be subjected to the target's policy. to the target network, where they may be subjected to target network
A second approach which carries a bit less overhead entails modifying policy. A second approach which carries a bit less overhead entails
the IRAC's policy configuration to reflect that of the remote network modifying the IRAC's policy configuration to reflect that of the
during the time the IRAC is connected to it via the tunnel. In this target network during the time the IRAC is connected. In this case,
case, traffic is not forced to loop through the target site prior to traffic is not forced to loop through the target site prior to
exiting or entering the IRAC. This requires some sort of policy exiting or entering the IRAC. This requires some sort of policy
download (or modification) capability as part of the SA establishment download (or modification) capability as part of the SA establishment
process. A third approach is to provide a configuration variable for process. A third approach is to provide a configuration variable for
the IRAC which permits specification of "tunnel-all", or "block all the IRAC which permits specification of "tunnel-all", or "block all
traffic not destined for the target network while the SA is up". traffic not destined for the target network while the SA is up".
In terms of IRAS configuration, it may be necessary to dynamically In terms of IRAS configuration, it may be necessary to dynamically
update the security policy database (SPD) when the remote user update the security policy database (SPD) when the remote user
connects. This is because transit selectors must be based upon connects. This is because transit selectors must be based upon
network address parameters, but these cannot be known a priori in the network address parameters, but these cannot be known a priori in the
skipping to change at page 23, line 24 skipping to change at page 20, line 24
cooperating on some level, but not to the degree that unbridled cooperating on some level, but not to the degree that unbridled
access between the two networks would be acceptable. Hence, this access between the two networks would be acceptable. Hence, this
scenario is characterized by limited access. The general topological scenario is characterized by limited access. The general topological
appearance is similar to this: appearance is similar to this:
CORP A CORP B CORP A CORP B
| | | |
+----+ | | +-----+ +----+ | | +-----+
|USER|---| |--| S1 | |USER|---| |--| S1 |
+----+ | +------++ ++------+ | +-----+ +----+ | +------++ ++------+ | +-----+
|---|SGW/FW||===internet===||SGW/FW|---| |---|SGW/FW||===Internet===||SGW/FW|---|
| +------++ ++------+ | +-----+ | +------++ ++------+ | +-----+
| SGW-A SGW-B |--| S2 | | SGW-A SGW-B |--| S2 |
| | +-----+ | | +-----+
This is purposely simplified in order to illustrate some basic This is purposely simplified in order to illustrate some basic
characteristics without getting bogged down in details. At the edge characteristics without getting bogged down in details. At the edge
of each network is a combination security gateway and firewall of each network is a combination security gateway and firewall
device. These are labeled "SGW-A" and "SGW-B". In this diagram, device. These are labeled "SGW-A" and "SGW-B". In this diagram,
corporation B wishes to provide a user from corporation A with access 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 to servers S1 and/or S2. This may be accomplished in one of several
skipping to change at page 26, line 30 skipping to change at page 23, line 32
service agreement of some sort. The user brings along a CORP-A laptop service agreement of some sort. The user brings along a CORP-A laptop
which is assigned a CORP-B address either statically or dynamically, which is assigned a CORP-B address either statically or dynamically,
and the user wishes to securely access resources on CORP-A's network and the user wishes to securely access resources on CORP-A's network
using this laptop. This scenario has the following appearance: using this laptop. This scenario has the following appearance:
CORP A CORP B CORP A CORP B
| | | |
+----+ | | +--------+ +----+ | | +--------+
|POP |---| |--| CORP-A | |POP |---| |--| CORP-A |
+----+ | +------++ ++------+ | | laptop | +----+ | +------++ ++------+ | | laptop |
|---|SGW/FW||===internet===||SGW/FW|---| +--------+ |---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ | | +------++ ++------+ |
+----+ | SGW-A SGW-B | +----+ | SGW-A SGW-B |
|FTP |---| | |FTP |---| |
+----+ | | +----+ | |
This is very similar to the telecommuter scenario, but it differs in This is very similar to the telecommuter scenario, but it differs in
several important ways. First, in this case there is often a SGW 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 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 significantly increased risk that a long-lived connection could
become accessible to someone other than the intended user. become accessible to someone other than the intended user.
skipping to change at page 28, line 7 skipping to change at page 25, line 9
is described in [ARCH] MUST be supported. is described in [ARCH] MUST be supported.
3.3.3 Policy Configuration Requirements 3.3.3 Policy Configuration Requirements
The policy configuration requirements in this scenario differ from The policy configuration requirements in this scenario differ from
those of the telecommuter, in that the laptop cannot be assigned a 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 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, 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 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 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 except via the laptop. On the other hand, Internet-bound traffic
could be subjected to this restriction if desired, and/or all 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 other than that between CORP-A and the laptop could be blocked for
the duration of the connection. the duration of the connection.
IRAC IRAC
---- ----
o support for IRAS update of IRAC policy MAY be provided. o support for IRAS update of IRAC policy MAY be provided.
o if IRAS update of IRAC policy is not supported, IRAC MAY o if IRAS update of IRAC policy is not supported, IRAC MAY
skipping to change at page 29, line 20 skipping to change at page 26, line 23
This is very similar to the extranet laptop scenario discussed above, 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- except that a higher degree of trust for CORP-B is required by CORP-
A. This scenario has the following appearance: A. This scenario has the following appearance:
CORP A CORP B CORP A CORP B
| | | |
+----+ | | +--------+ +----+ | | +--------+
|POP |---| |--| CORP-B | |POP |---| |--| CORP-B |
+----+ | +------++ ++------+ | |desktop | +----+ | +------++ ++------+ | |desktop |
|---|SGW/FW||===internet===||SGW/FW|---| +--------+ |---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ | | +------++ ++------+ |
+----+ | SGW-A SGW-B | +----+ | SGW-A SGW-B |
|FTP |---| | |FTP |---| |
+----+ | | +----+ | |
3.4.1 Authentication Requirements 3.4.1 Authentication Requirements
The authentication requirements for the desktop extranet scenario are The authentication requirements for the desktop extranet scenario are
very similar to those of the extranet laptop scenario discussed very similar to those of the extranet laptop scenario discussed
above. The primary difference lies in the authentication type which above. The primary difference lies in the authentication type which
skipping to change at page 31, line 7 skipping to change at page 28, line 8
order to render these modifications transparent to the IPsec order to render these modifications transparent to the IPsec
implementation. implementation.
If a firewall situated at the edge of the host network cannot be If a firewall situated at the edge of the host network cannot be
configured to pass protocols in the IPsec suite, then some configured to pass protocols in the IPsec suite, then some
mechanism must be provided which converts the data stream to one mechanism must be provided which converts the data stream to one
which the firewall may be configured to pass. If the firewall can which the firewall may be configured to pass. If the firewall can
be configured to pass IPsec protocols, then this must be be configured to pass IPsec protocols, then this must be
accomplished prior to connection establishment. accomplished prior to connection establishment.
3.5 Remote Dialup Laptop (Road Warrior) Access 3.5 Public System to Target Network
This is a very common remote access scenario, and is virtually
indistinguishable from the telecommuter scenario, except that the
connections are typically dialup only, and hence, short-lived.
Refer to section 3.1.1 for details.
3.6 Third Party System to Target Network
This scenario entails a traveling user connecting to the target This scenario entails a traveling user connecting to the target
network using a system provided by a third party. A commonly cited network using a public system owned by someone else. A commonly
example is an airport kiosk. This looks very similar to the cited example is an airport kiosk. This looks very similar to the
extranet desktop scenario, except that in the extranet scenario, extranet desktop scenario, except that in the extranet scenario,
CORP-A might have a trust relationship with CORP-B, whereas in this CORP-A might have a trust relationship with CORP-B, whereas in this
scenario, CORP-A may not trust a third-party system. Note that a scenario, CORP-A may not trust a publically accessible system. Note
trust relationship between CORP-A and the owner of the third-party that a trust relationship between CORP-A and the owner of the
system (TPS) may exist, but in many cases will not. public system may exist, but in many cases will not.
3.6.1 Authentication Requirements 3.5.1 Authentication Requirements
There are two variations to this scenario. In the first, no trust There are two variations to this scenario. In the first, no trust
relationship exists between the target network and the provider of relationship exists between the target network and the borrowed
the borrowed system. In the second, some trust relationship does system. In the second, some trust relationship does exist. In the
exist. In the case where no trust relationship exists, machine case where no trust relationship exists, machine authentication is
authentication is out of the question, as it is meaningless in this out of the question, as it is meaningless in this context. Further,
context. Further, since such a system could easily capture a since such a system could easily capture a passphrase, use of a
passphrase, use of a static passphrase would seem to be ill- static passphrase from such a system would seem to be ill-advised.
advised.
If a one-time passphrase were used, this would mitigate the risk of If a one-time passphrase were used, this would mitigate the risk of
passphrase capture by the third-party system. On the other hand, if passphrase capture by the public system. On the other hand, if it
it is acknowledged that such capture is a real threat (i.e. the is acknowledged that such capture is a real threat (i.e. the system
system itself is malicious), then it must also be recognized that itself is malicious), then it must also be recognized that any data
any data transmitted and received via the resulting session would transmitted and received via the resulting session would not be
not be confidential or reliable with respect to this malicious confidential or reliable with respect to this malicious system, and
system, and that the system could not be trusted to have actually that the system could not be trusted to have actually disconnected
disconnected when the user walks away. This suggests that accessing when the user walks away. This suggests that accessing non-trivial
non-trivial information from such a system would be imprudent. information from such a system would be imprudent.
Another possible user authentication option would be a smartcard. Another possible user authentication option would be a smartcard.
However, many smartcards require a pin or passphrase to "unlock" However, many smartcards require a pin or passphrase to "unlock"
them, in some cases requiring that this be entered via the keyboard them, which requires some level of trust in the kiosk to not record
of the accessing system. This requires some level of trust in the the pin. Hence, this approach suffers from drawbacks similar to
TPS to not record the pin. Hence, this approach suffers from those of the static passphrase in this regard. The primary
drawbacks similar to those of the static passphrase in this regard. difference would be that the pin/passphrase could not be used alone
The primary difference would be that the pin/passphrase could not for access in the smartcard case.
be used alone for access in the smartcard case.
In cases where a trust relationship with the owner of the TPS In cases where a trust relationship with the owner of the public
exists, the trust level would modulate the risk levels discussed system exists, the trust level would modulate the risk levels
above. For example, if a sufficient level of trust for the system discussed above. For example, if a sufficient level of trust for
owner exists, use of a static passphrase might present no more risk the system owner exists, use of a static passphrase might present
than if this were permitted from a system owned by the accessed no more risk than if this were permitted from a system owned by the
corporation. However, the primary benefit of such a trust accessed target. However, the primary benefit of such a trust
relationship would be derived from the ability to authenticate the relationship would be derived from the ability to authenticate the
machine from which the user is attempting access. For example, a machine from which the user is attempting access. For example, a
security policy requiring that remote access only be permitted with security policy requiring that remote access only be permitted with
combined user/machine authentication might be effected, with combined user/machine authentication might be effected, with
further control regarding which machines were allowed. further control regarding which machines were allowed.
An additional issue to be dealt with in either case pertains to 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 verification of the identity of the IRAS. If the IRAC were to be
misdirected somehow, a man in the middle attack could be effected, misdirected somehow, a man in the middle attack could be effected,
with the obtained password being then used for malicious access to with the obtained password being then used for malicious access to
the true IRAS. Note that even a one-time password mechanism offers the true IRAS. Note that even a one-time password mechanism offers
little protection in this case. In order to avert such an attack, little protection in this case. In order to avert such an attack,
the TPS must possess some certifiable or secret knowledge of the the IRAC must possess some certifiable or secret knowledge of the
IRAS prior to attempting to connect, and the user must trust the IRAS prior to attempting to connect. Note that in the case where no
TPS to accurately verify this information. Note that in the case trust relationship exists, this is not possible.
where no trust relationship exists, this is not possible.
To summarize, the following are the authentication requirements for To summarize, the following are the authentication requirements for
the IRAS and IRAC: the IRAS and IRAC:
IRAS IRAS
---- ----
o machine authentication MUST be provided. o machine authentication MUST be provided.
IRAC IRAC
skipping to change at page 33, line 4 skipping to change at page 29, line 41
IRAC IRAC
---- ----
o in cases where no trust relationship exists between the o in cases where no trust relationship exists between the
accessed network and the system owner, sensitive data accessed network and the system owner, sensitive data
SHOULD NOT be transmitted in either direction. SHOULD NOT be transmitted in either direction.
o in cases where a trust relationship exists between the o in cases where a trust relationship exists between the
accessed network and the system owner, machine authentication accessed network and the system owner, machine authentication
SHOULD be supported. SHOULD be supported.
o in cases where a trust relationship exists between the o in cases where a trust relationship exists between the
accessed network and the system owner, a static passphrase accessed network and the system owner, a static passphrase
MAY be used in conjunction with machine-level authentication MAY be used in conjunction with machine-level authentication
of the IRAC system. of the IRAC system.
o frequent renewal of user authentication MUST occur o frequent renewal of user authentication MUST occur
3.6.2 Device Configuration Requirements 3.5.2 Device Configuration Requirements
None. None.
3.6.3 Policy Configuration Requirements 3.5.3 Policy Configuration Requirements
None. None.
3.6.4 Auditing Requirements 3.5.4 Auditing Requirements
The auditing requirements in this scenario are the same as for the The auditing requirements in this scenario are the same as for the
telecommuter scenario. Session start/end times must collected. telecommuter scenario. Session start/end times must collected.
Reliable derivation of session end time requires that the IRAC Reliable derivation of session end time requires that the IRAC
somehow periodically signify that the connection remains active. somehow periodically signify that the connection remains active.
This is implied if the IRAS receives data from the IRAC over the 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 connection, but in cases where no data is sent for some period of
time, a signaling mechanism is required by which the IRAC indicates time, a signaling mechanism is required by which the IRAC indicates
that the connection remains in use. that the connection remains in use.
3.6.5 Intermediary Traversal Requirements 3.5.5 Intermediary Traversal Requirements
If the address of the IRAC system is globally routable, and no If the address of the IRAC system is globally routable, and no
intermediate devices between the IRAC and the IRAS perform NAPT intermediate devices between the IRAC and the IRAS perform NAPT
operations on the data stream, then there are no additional operations on the data stream, then there are no additional
requirements in this regard. If NAPT operations are performed on requirements in this regard. If NAPT operations are performed on
the data stream, some mechanism must be provided in order to render the data stream, some mechanism must be provided in order to render
these modifications transparent to the IPsec implementation. these modifications transparent to the IPsec implementation.
4. Scenario Commonalities 4. Scenario Commonalities
skipping to change at page 35, line 12 skipping to change at page 31, line 45
[KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens,
"Remote Authentication Dial In User Service "Remote Authentication Dial In User Service
(RADIUS)", RFC2138 (RADIUS)", RFC2138
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[L2TP] Townsley, M., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
Palter, B., "Layer Two Tunneling Protocol L2TP", RFC2661,
August, 1999
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", Std 51,
RFC1661, July 1994
[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999
8. Acknowledgements 8. Acknowledgements
The editors would like to acknowledge the many helpful comments of Sara The editors would like to acknowledge the many helpful comments of Sara
Bitan, Steve Kent, Mark Townsley, and other members of the ipsra working Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and other
group who have made helpful comments on this work. members of the ipsra working group who have made helpful comments on this work.
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
skipping to change at page 36, line 24 skipping to change at page 33, line 4
o delete mobility requirements o delete mobility requirements
o add accounting requirements o add accounting requirements
o extensively modify discussion of endpoint authentication, and o extensively modify discussion of endpoint authentication, and
machine vs. user authentication machine vs. user authentication
o delete roaming/wireless users and user-to-user connections from o delete roaming/wireless users and user-to-user connections from
Scenarios bullet list Scenarios bullet list
o Add discussion of trojan horse applications to telecommuter scenario o Add discussion of trojan horse applications to telecommuter scenario
o add statement about encouraging migration to PKI-based systems to o add statement about encouraging migration to PKI-based systems to
legacy compatibility section. legacy compatibility section.
o clarified language in section 2.3 (Security Policy Configuration) o clarified language in section 2.3 (Security Policy Configuration)
01 to 02: 01 to 02:
o add n-factor authentication to general requirements o add n-factor authentication to general requirements
o change "accounting" to "auditing" o change "accounting" to "auditing"
o delete incoming/outgoing octet counts from auditing requirements o delete incoming/outgoing octet counts from auditing requirements
o added intermediary traversal requirements o added intermediary traversal requirements
o numerous general edits for clarity o numerous general edits for clarity
02 to 03: 02 to 03:
o minor edits throughout o minor edits throughout
o significantly modified introduction to provide discussion o significantly modified introduction to provide discussion
of L2TP/IPsec of L2TP/IPsec
o replaced "corporate" with "target" when referring to the o replaced "corporate" with "target" when referring to the
network the IRAS protects network the IRAS protects
o modified discussion in section 3.1.1 o modified discussion in section 3.1.1
o changed SHOULD to MAY in section 3.2.2, support for address o changed SHOULD to MAY in section 3.2.2, support for address
assignment based on authenticated identity assignment based on authenticated identity
o change "public" to "third-party" in section 3.6
03 to 04
o minor edits throughout
o removed discussion of L2TP/IPsec from introduction
o changed some of the remaining "corporate" references
to "target"
o added "NAPT" to general terminology definitions
o collapsed "road warrior" scenario into remote telecommuter
scenario
 End of changes. 58 change blocks. 
369 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/