|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
This is very similar to the telecommuter scenario, but it differs in
several important ways. First, in this case there is often a SGW
and/or firewall at the edge of CORP-B's site. Second, there may be a
significantly increased risk that a long-lived connection could
become accessible to someone other than the intended user.
3.3.1 Authentication Requirements
In most cases, the only acceptable connections from CORP-A's
perspective are between the laptop and either SGW-A or the CORP-A
servers the laptop wishes to access. Most of the considerations
applied to the telecommuter also apply here, and user-level
authentication is required to provide assurance that the user who
initiated the connection is still the active user. As an added
precaution, a combination of user-level and machine-level
authentication may be warranted in some cases. Further, in either
case this authentication should be renewed frequently.
To summarize, the following are the authentication requirements for
the IRAS and IRAC:
IRAS
----
o machine authentication MUST be provided.
IRAC
----
o support for machine authentication SHOULD be provided
o support for user authentication MUST be provided
o support for a combination of user and machine authentication
SHOULD be provided
o periodic renewal of user authentication MUST occur
3.3.2 Device Configuration Requirements
The device configuration requirements in this scenario are the same
as for the telecommuter, i.e., the laptop may be assigned a virtual
presence on the corporate network, and if so, will require full
infrastructure configuration.
To summarize, the following are the device configuration requirements
for the IRAC:
o support for a virtual address MAY be provided
o if VIP support is provided, support for all device-related
parameters listed in section 2.2 above SHOULD be supported
o support for address assignment based upon authenticated
identity SHOULD be supported
o if authenticated address assignment is not supported, an
identity-based dynamic policy update mechanism such as is
described in [ARCH] MUST be supported.
3.3.3 Policy Configuration Requirements
The policy configuration requirements in this scenario differ from
those of the telecommuter, in that the laptop cannot be assigned a
policy which requires all traffic to be forwarded to CORP-A via the
tunnel. This is due to the fact that the laptop has a CORP-B
address, and as such, may have traffic destined to CORP-B. If this
traffic were tunneled to CORP-A, there might be no return path to
CORP-B except via the laptop. On the other hand, Internet-bound
traffic could be subjected to this restriction if desired, and/or all
traffic other than that between CORP-A and the laptop could be
blocked for the duration of the connection.
IRAC
----
o support for IRAS update of IRAC policy MAY be provided.
o if IRAS update of IRAC policy is not supported, IRAC MAY
support IRAS directives to "block-all" for non-tunneled
traffic.
o IRAC SHOULD provide ability to configure for "tunnel-all"
and/or "block-all" for traffic not destined for the remote
network to which IPsec remote access is being provided.
3.3.4 Auditing Requirements
The auditing requirements in this scenario are the same as for the
telecommuter scenario. Session start/end times must be collected.
Reliable derivation of session end time requires that the IRAC
somehow periodically signify that the connection remains active.
This is implied if the IRAS receives data from the IRAC over the
connection, but in cases where no data is sent for some period of
time, a signaling mechanism is required by which the IRAC indicates
that the connection remains in use.
3.3.5 Intermediary Traversal Requirements
If the address assigned by the host network to the IRAC system is
globally routable, and no intermediate devices between the IRAC and
the IRAS perform NAPT operations on the data stream, then there are
no additional requirements in this regard. If NAPT operations are
performed on the data stream, some mechanism must be provided in
order to render these modifications transparent to the IPsec
implementation.
If a firewall situated at the edge of the host network cannot be
configured to pass protocols in the IPsec suite, then some mechanism
must be provided which converts the data stream to one which the
firewall may be configured to pass. If the firewall can be
configured to pass IPsec protocols, then this must be accomplished
prior to connection establishment.
3.4 Extranet Desktop to Home Corporate Net
This is very similar to the extranet laptop scenario discussed above,
except that a higher degree of trust for CORP-B is required by
CORP-A. This scenario has the following appearance:
CORP A CORP B
| |
+----+ | | +--------+
|POP |---| |--| CORP-B |
+----+ | +------++ ++------+ | |desktop |
|---|SGW/FW||===Internet===||SGW/FW|---| +--------+
| +------++ ++------+ |
+----+ | SGW-A SGW-B |
|FTP |---| |
+----+ | |
3.4.1 Authentication Requirements
The authentication requirements for the desktop extranet scenario are
very similar to those of the extranet laptop scenario discussed
above. The primary difference lies in the authentication type which
may be used, i.e., in the laptop case, CORP-A can derive some
assurance that the connection is coming from one of CORP-A's systems
if a securely stored machine credential is stored on and used by on
the laptop. In the desktop case this is not possible, since CORP-A
does not own the IRAC system.
To summarize, the following are the authentication requirements for
the IRAS and IRAC:
IRAS
----
o machine authentication MUST be provided.
IRAC
----
o support for machine authentication MAY be provided
o support for user authentication MUST be provided
o support for a combination of user and machine authentication
MAY be provided
o periodic renewal of user authentication MUST occur
3.4.2 Device Configuration Requirements
The device configuration requirements in this scenario are the same
as for the laptop extranet scenario, i.e., the desktop system may be
assigned a virtual presence on the corporate network, and if so, will
require full infrastructure configuration. However, this seems less
likely than in the laptop scenario, given CORP-A's lack of control
over the software configuration of CORP-B's desktop system.
3.4.3 Policy Configuration Requirements
The policy configuration requirements are quite similar to those of
the extranet laptop, except that in this scenario there is even less
control over CORP-B's desktop than there would be over the laptop.
This means it may not be possible to restrict traffic in any way at
the desktop system.
3.4.4 Auditing Requirements
The auditing requirements in this scenario are the same as for the
telecommuter scenario. Session start/end times must be collected.
Reliable derivation of session end time requires that the IRAC
somehow periodically signify that the connection remains active.
This is implied if the IRAS receives data from the IRAC over the
connection, but in cases where no data is sent for some period of
time, a signaling mechanism is required by which the IRAC indicates
that the connection remains in use.
3.4.5 Intermediary Traversal Requirements
If the address assigned by the host network to the IRAC system is
globally routable, and no intermediate devices between the IRAC and
the IRAS perform NAPT operations on the data stream, then there are
no additional requirements in this regard. If NAPT operations are
performed on the data stream, some mechanism must be provided in
order to render these modifications transparent to the IPsec
implementation.
If a firewall situated at the edge of the host network cannot be
configured to pass protocols in the IPsec suite, then some mechanism
must be provided which converts the data stream to one which the
firewall may be configured to pass. If the firewall can be
configured to pass IPsec protocols, then this must be accomplished
prior to connection establishment.
3.5 Public System to Target Network
This scenario entails a traveling user connecting to the target
network using a public system owned by someone else. A commonly
cited example is an airport kiosk. This looks very similar to the
extranet desktop scenario, except that in the extranet scenario,
CORP-A might have a trust relationship with CORP-B, whereas in this
scenario, CORP-A may not trust a publicly accessible system. Note
that a trust relationship between CORP-A and the owner of the public
system may exist, but in many cases will not.
3.5.1 Authentication Requirements
There are two variations to this scenario. In the first, no trust
relationship exists between the target network and the borrowed
system. In the second, some trust relationship does exist. In the
case where no trust relationship exists, machine authentication is
out of the question, as it is meaningless in this context. Further,
since such a system could easily capture a passphrase, use of a
static passphrase from such a system would seem to be ill-advised.
If a one-time passphrase were used, this would mitigate the risk of
passphrase capture by the public system. On the other hand, if it is
acknowledged that such capture is a real threat (i.e., the system
itself is malicious), then it must also be recognized that any data
transmitted and received via the resulting session would not be
confidential or reliable with respect to this malicious system, and
that the system could not be trusted to have actually disconnected
when the user walks away. This suggests that accessing non-trivial
information from such a system would be imprudent.
Another possible user authentication option would be a smartcard.
However, many smartcards require a pin or passphrase to "unlock"
them, which requires some level of trust in the kiosk to not record
the pin. Hence, this approach suffers from drawbacks similar to
those of the static passphrase in this regard. The primary
difference would be that the pin/passphrase could not be used alone
for access in the smartcard case.
In cases where a trust relationship with the owner of the public
system exists, the trust level would modulate the risk levels
discussed above. For example, if a sufficient level of trust for the
system owner exists, use of a static passphrase might present no more
risk than if this were permitted from a system owned by the accessed
target. However, the primary benefit of such a trust relationship
would be derived from the ability to authenticate the machine from
which the user is attempting access. For example, a security policy
requiring that remote access only be permitted with combined
user/machine authentication might be effected, with further control
regarding which machines were allowed.
An additional issue to be dealt with in either case pertains to
verification of the identity of the IRAS. If the IRAC were to be
misdirected somehow, a man in the middle attack could be effected,
with the obtained password being then used for malicious access to
the true IRAS. Note that even a one-time password mechanism offers
little protection in this case. In order to avert such an attack,
the IRAC must possess some certifiable or secret knowledge of the
IRAS prior to attempting to connect. Note that in the case where no
trust relationship exists, this is not possible.
To summarize, the following are the authentication requirements for
the IRAS and IRAC:
IRAS
----
o machine authentication MUST be provided.
IRAC
----
o in cases where no trust relationship exists between the
accessed network and the system owner, sensitive data SHOULD
NOT be transmitted in either direction.
o in cases where a trust relationship exists between the accessed
network and the system owner, machine authentication SHOULD be
supported.
o in cases where a trust relationship exists between the accessed
network and the system owner, a static passphrase MAY be used
in conjunction with machine-level authentication of the IRAC
system.
o frequent renewal of user authentication MUST occur
3.5.2 Device Configuration Requirements
None.
3.5.3 Policy Configuration Requirements
None.
3.5.4 Auditing Requirements
The auditing requirements in this scenario are the same as for the
telecommuter scenario. Session start/end times must be collected.
Reliable derivation of session end time requires that the IRAC
somehow periodically signify that the connection remains active.
This is implied if the IRAS receives data from the IRAC over the
connection, but in cases where no data is sent for some period of
time, a signaling mechanism is required by which the IRAC indicates
that the connection remains in use.
3.5.5 Intermediary Traversal Requirements
If the address of the IRAC system is globally routable, and no
intermediate devices between the IRAC and the IRAS perform NAPT
operations on the data stream, then there are no additional
requirements in this regard. If NAPT operations are performed on the
data stream, some mechanism must be provided in order to render these
modifications transparent to the IPsec implementation.
4. Scenario Commonalities
As we examine the various remote access scenarios, a general set of
common requirements emerge. Following is a summary:
o Support for user authentication is required in almost all
scenarios
o Machine authentication for the IRAS is required in all scenarios
o A mechanism for providing device configuration for the IRAC is
required in most scenarios. Such a mechanism must be extensible.
o Machine authentication for IRAC is generally only useful when
combined with user authentication. Combined user and machine
authentication is useful in some scenarios.
o Dynamic IRAC policy configuration is useful in several scenarios.
o Most scenarios require auditing for session start/stop times.
o An intermediary traversal mechanism may be required in any of the
scenarios.
5. Security Considerations
The topic of this document is secure remote access. Security
considerations are discussed throughout the document.
6. References
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RADIUS] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC2865, June 2000.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC2409, November 1998.
7. Acknowledgements
The editors would like to acknowledge the many helpful comments of
Sara Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and
other members of the ipsra working group who have made helpful
comments on this work.
8. Editors' Addresses
Scott Kelly
Airespace
110 Nortech Pkwy
San Jose CA 95134 USA
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Sankar Ramamoorthi
Juniper Networks
1194 North Mathilda Ave
Sunnyvale CA 94089-1206 USA
Phone: +1 (408) 936-2630
EMail: sankarr@juniper.net
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.