idnits 2.17.1 draft-ietf-ipsra-reqmts-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 11, but not defined -- Looks like a reference, but probably isn't: '3' on line 144 == Unused Reference: 'KEYWORDS' is defined on line 1384, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec Remote Access Working Group Scott Kelly, RedCreek 3 INTERNET-DRAFT Sankar Ramamoorthi, Nexsi 4 draft-ietf-ipsra-reqmts-04.txt August, 2001 6 Requirements for IPsec Remote Access Scenarios 8 Status of This Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of [RFC2026]. Internet Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments on this document should be sent to the IETF IPsec remote 29 access discussion list (ietf-ipsra@vpnc.org). 31 Abstract 33 IPsec offers much promise as a secure remote access mechanism. 34 However, there are a number of differing remote access scenarios, 35 each having some shared and some unique requirements. A thorough 36 understanding of these requirements is necessary in order to 37 effectively evaluate the suitability of a specific set of mechanisms 38 for any particular remote access scenario. This document enumerates 39 the requirements for a number of common remote access scenarios. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4 45 1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 5 46 1.3 General Terminology . . . . . . . . . . . . . . . . . . . . . . 5 47 1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . 6 48 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 2.1 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 7 50 2.1.1 Machine-Level Authentication . . . . . . . . . . . . . . . . . 7 51 2.1.2 User-Level Authentication . . . . . . . . . . . . . . . . . . 8 52 2.1.3 Combined User/Machine Authentication . . . . . . . . . . . . . 8 53 2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . . 9 54 2.1.5 Compatibility With Legacy Remote Access Mechanisms . . . . . . 10 55 2.2 Remote Host Configuration . . . . . . . . . . . . . . . . . . . 11 56 2.3 Security Policy Configuration . . . . . . . . . . . . . . . . . 12 57 2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . . . . . 14 59 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . . . . . 15 61 3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . . 16 62 3.1.2 Device Configuration Requirements . . . . . . . . . . . . . . 17 63 3.1.3 Policy Configuration Requirements . . . . . . . . . . . . . . 18 64 3.1.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 19 65 3.1.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 19 66 3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . . 20 67 3.2.1 Authentication Requirements . . . . . . . . . . . . . . . . . 21 68 3.2.2 Device Configuration Requirements . . . . . . . . . . . . . . 21 69 3.2.3 Policy Configuration Requirements . . . . . . . . . . . . . . 22 70 3.2.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 22 71 3.2.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 22 72 3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . . . . . 23 73 3.3.1 Authentication Requirements . . . . . . . . . . . . . . . . . 23 74 3.3.2 Device Configuration Requirements . . . . . . . . . . . . . . 24 75 3.3.3 Policy Configuration Requirements . . . . . . . . . . . . . . 24 76 3.3.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 25 77 3.3.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 25 78 3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . . 26 79 3.4.1 Authentication Requirements . . . . . . . . . . . . . . . . . 26 80 3.4.2 Device Configuration Requirements . . . . . . . . . . . . . . 27 81 3.4.3 Policy Configuration Requirements . . . . . . . . . . . . . . 27 82 3.4.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 27 83 3.4.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 27 84 3.5 Public System to Target Network . . . . . . . . . . . . . . . . 28 85 3.5.1 Authentication Requirements . . . . . . . . . . . . . . . . . 28 86 3.5.2 Device Configuration Requirements . . . . . . . . . . . . . . 29 87 Table of Contents 89 3.5.3 Policy Configuration Requirements . . . . . . . . . . . . . . 30 90 3.5.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 30 91 3.5.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 30 92 4. Scenario Commonalities . . . . . . . . . . . . . . . . . . . . . 30 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 31 94 6. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31 97 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 32 98 Appendix A: Change Log . . . . . . . . . . . . . . . . . . . . . . . 32 99 1. Introduction 101 Until recently, remote access has typically been characterized by 102 dial-up users accessing the target network via the Public Switched 103 Telephone Network (PSTN), with the dial-up connection terminating at 104 a Network Access Server (NAS) within the target domain. The protocols 105 facilitating this have usually been PPP-based, and access control, 106 authorization, and accounting functions have typically been provided 107 using one or more of a number of available mechanisms, including 108 RADIUS [RADIUS]. 110 Note that for such access, it has often been assumed that the 111 communications infrastructure supporting the ISP connection (the 112 PSTN) is relatively secure, and poses no significant threats to 113 communications integrity or confidentiality. Based on this 114 assumption, connection security has been limited to access control at 115 the NAS based on username/passphrase pairs. In reality, PSTN dialup 116 connections have never been impervious to a determined adversary. 118 The availability of widespread broadband access, in concert with the 119 desire to reduce the cost of PSTN toll access, have driven the 120 development of Internet-based remote access mechanisms. In some 121 cases, PPP-based tunneling mechanisms have been used to provide 122 remote access by allowing the dial user to first access a local ISP 123 account, and then tunnel an additional PPP connection over the 124 Internet into the target network. In the case of broadband users, 125 such connections are tunneled directly over the Internet. While these 126 mechanisms have been lacking in terms of security features, the 127 increasing availability of IPsec renders it possible to provide more 128 secure remote access to the remote resources via the Internet. 130 Remote access via the Internet has numerous benefits, financial and 131 otherwise. However, security is paramount, and this presents strong 132 incentives for migration from the old dial-up model to a more secure 133 IPsec-based remote access model. Meeting the security requirements of 134 various classes of remote access users presents a number of 135 challenges. It is the aim of this document to explore and enumerate 136 the requirements of various IPsec remote access scenarios, without 137 suggesting particular solutions for them. 139 1.1 Requirements Terminology 141 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 142 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 143 document, are to be interpreted as described in [3]. 145 1.2 Reader Prerequisites 147 Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to 148 understanding the concepts discussed here. Familiarity with concepts 149 relating to Public Key Infrastructures (PKIs) is also necessary. 150 Familiarity with RADIUS, PPP, PPTP, L2F, L2TP, and other remote 151 access support protocols will also be helpful, though not strictly 152 necessary. 154 1.3 General Terminology 156 o Remote Access - this term is used to refer to the case in which 157 the remote user does not necessarily reside at a fixed location, 158 i.e. in which the user's IP address is not fixed, and therefore 159 usually not known prior to connection establishment. 161 o Secure Remote Access - this term refers to remote access which is 162 secured using elements of the IPsec protocol suite. 164 o IPsec Remote Access Client (IRAC)- this term is used to refer to 165 the remote access user's system. 167 o IPsec Remote Access Server (IRAS) - this term refers to the device 168 providing access to the target network. An alternative term 169 is "Security Gateway". 171 o Security GateWay (SGW) - this refers to the device providing 172 access to the target network. An alternative term is IRAS. 174 o Virtual IP address (VIP) - this term describes an address from 175 a subnet local to the target network which is assigned to a 176 remote client, giving the appearance that the remote client 177 actually resides on the target network. 179 o Machine-Level Authentication - this term describes the 180 case where the identity of a machine is verified by virtue 181 of the machine's possession and application of some 182 combination of authenticators. For a more complete definition, 183 see section 2. 185 o User-Level Authentication - this term describes the case 186 where the identity of a user (as opposed to that of a machine) 187 is verified by virtue of the user's possession and application 188 of some combination of authenticators. For a more complete 189 definition, see section 2. 191 o NAPT - Network Address/Port Translation 193 1.4 Document Organization 195 The balance of this document is organized as follows: First, there is 196 a general overview of the basic requirements categories, including 197 definitions relevant to these categories. Following this is a section 198 devoted to each remote access scenario. Within each of these sections 199 there are subsections detailing requirements specific to that 200 scenario in each of the following areas: endpoint authentication, 201 remote host configuration, policy configuration, auditing, and 202 intermediary traversal. 204 2. Overview 206 In a very general sense, all secure remote access scenarios have a 207 similar high-level appearance: 209 target network 210 | 211 | +---+ 212 +-------------+ +-----------+ |---| | 213 |remote access| Internet | security | | +---+ 214 | client |=============| gateway |--| 215 | (IRAC) | |(SGW/IRAS) | | +---+ 216 +-------------+ +-----------+ |---| | 217 | +---+ 219 In all cases, a remote client wishes to securely access resources 220 either behind a SGW or on an IPsec-protected host, and/or wishes to 221 provide other (specific) systems with secure access to the client's 222 own resources. There are numerous details which may differ, depending 223 on the particular scenario. For example, the IRAC may be within 224 another corporate network, or connected to an ISP via dialup, DSL, or 225 CATV media. There may be additional intermediaries between the remote 226 client and the security gateway, but ultimately, all of these 227 configurations may be viewed somewhat equivalently from a high level. 229 In general, there are several basic categories of requirements 230 relevant to secure remote access scenarios, including endpoint 231 authentication, remote host configuration, security policy 232 configuration, auditing, and intermediary traversal. Endpoint 233 authentication refers to verification of the identities of the 234 communication partners (e.g. the IRAC and the IRAS). Remote host 235 configuration refers to the device configuration parameters of the 236 IRAC system. Security policy configuration refers to IPsec policy 237 configuration of both the security gateway and the remote host, and 238 might also be termed "access control and authorization 239 configuration". Auditing refers to the generation and collection of 240 connection status information which is required for the purpose of 241 maintaining the overall security and integrity of the connected 242 networks. Intermediary traversal refers to the ability to pass 243 secured traffic across intermediaries, some of which may modify the 244 packets in some manner. Such intermediaries include NAPT and firewall 245 devices. These various categories are treated in more detail below. 247 2.1 Endpoint Authentication 249 Before discussing endpoint authentication with respect to remote 250 access, it is important to distinguish between data source 251 authentication and end user authentication. Data source 252 authentication in the IPsec context consists in providing assurance 253 that a network packet originates from a specific endpoint, typically 254 a user, host, or application. IPsec offers mechanisms for this via AH 255 or ESP. End user authentication within the IPsec context consists in 256 providing assurance that the endpoint is what or who it claims to be. 257 IPsec currently offers mechanisms for this as part of IKE [IKE]. 259 While the two types of authentication differ, they are not unrelated. 260 In fact, data source authentication relies upon endpoint 261 authentication, because it is possible to inject packets with a 262 particular IP address into the Internet from many arbitrary 263 locations, so that we cannot be certain in many instances that a 264 packet actually originates from a particular host, or even from the 265 network upon which that host resides. To resolve this, one must 266 first authenticate the particular endpoint somehow, and then bind the 267 addressing information (e.g. IP address, protocol, port) of this 268 endpoint into the trust relationship established by the 269 authentication process. 271 In the context of secure remote access, the authenticated entity may 272 be a machine, a user (application), or both. The authentication 273 methods currently supported by IPsec range from preshared secrets to 274 various signature and encryption schemes employing private keys and 275 their corresponding public key certificates. These mechanisms may be 276 used to authenticate the end user alone, the device alone, or both 277 the end user and the device. These are each discussed in more detail 278 below. 280 2.1.1 Machine-Level Authentication 282 In the case where no user input is required in order for an 283 authentication credential to be used, the entity authenticated will 284 primarily be the device in which the credential is stored, and the 285 level of derived assurance regarding this authentication is directly 286 related to how securely the machine's credential is maintained during 287 both storage and use. That is, a shared secret or a private key 288 corresponding to a public key certificate may be either stored within 289 the device or contained in another device which is securely 290 accessible by the device (e.g. a smartcard). If the knowledge 291 required for the use of such authentication credentials is entirely 292 contained within the subject device (i.e. no user input is required), 293 then it is problematic to state that such credential usage 294 authenticates anything other than the subject device. 296 In some cases, a user may be required to satisfy certain criteria 297 prior to being given access to stored credentials. In such cases, the 298 level of user authentication provided by the use of such credentials 299 is somewhat difficult to derive. If sufficiently strong access 300 controls exist for the system housing the credential, then there may 301 be a strong binding between the authorized system user and the 302 credential. However, at the time the credential is presented, the 303 IRAS itself has no such assurance. That is, the IRAS in isolation may 304 have some level of assurance that a particular device (the one in 305 which the credential resides) is the one from which access is being 306 attempted, but there is no explicit assurance regarding the identity 307 of the user of the system. In order for the IRAS to derive additional 308 assurance regarding the user identity, an additional user credential 309 of some sort would be required. This is discussed further below. 311 2.1.2 User-Level Authentication 313 In some cases, the user may possess an authentication token 314 (preshared key, private key, passphrase, etc.), and may provide this 315 or some derivative of this whenever authentication is required. If 316 this token or derivative is delivered directly to the other endpoint 317 without modification by the IRAC system, and if the IRAC system 318 provides no further credentials of its own, then it is the user alone 319 which has been authenticated. That is, while there may be some 320 assurance as to the network address from which the user is 321 originating packets, there is no assurance as to the particular 322 machine from which the user is attempting access. 324 2.1.3 Combined User/Machine Authentication 326 To authenticate both the user and the system, user input of some sort 327 is required in addition to a credential which is securely stored upon 328 the device. In some cases, such user input may be used in order to 329 "complete" the credential stored on the device (e.g. a private key is 330 password-encrypted), while in others the user's input is supplied 331 independently of the stored credential. In the case where the 332 passphrase is applied to the credential prior to use, the level of 333 assurance derived from successful application of the credential 334 varies according to your viewpoint. 336 From the perspective of a system consisting of user, IRAC, IRAS, and 337 a collection of system protections and security procedures, it may be 338 said that the user has been authenticated to an extent which depends 339 upon the strength of the security procedures and system protections 340 which are in place. However, from the perspective of the IRAS alone, 341 there is little assurance with respect to user identity. That is, 342 schemes requiring that stored credentials be modified by user input 343 prior to use may only be said to provide user-level authentication 344 within the context of the larger system, and then, the level of 345 assurance derived is directly proportional to the weakest security 346 attribute of the entire system. 348 When considering remote access from a general perspective, 349 assumptions regarding the overall system are liable to prove 350 incorrect. This is because the IRAS and the IRAC may not be within 351 the same domain of control; extranet scenarios are a good example of 352 this. Hence, the most desirable joint user/machine authentication 353 mechanisms in this context are those which provide a high level of 354 assurance to both the IRAS and the IRAC, independently of the larger 355 system of which the user, IRAS, and IRAC are a part. 357 2.1.4 Remote Access Authentication 359 In the general case for remote access, authentication requirements 360 are typically asymmetric. From the IRAC's perspective, it is 361 important to ensure that the IRAS at the other end of the connection 362 is indeed what it seems to be, and not some rogue system masquerading 363 as the SGW. That is, the IRAC requires machine-level authentication 364 for the IRAS. This is fairly straightforward, given the 365 authentication mechanisms supported by IKE and IPsec. Further, this 366 sort of authentication tends to persist through time, although the 367 extent of this persistence depends upon the mechanism chosen. 369 While machine-level authentication for the IRAS is sufficient, this 370 is not the case for the IRAC. Here, it is often important to know 371 that the entity at the other end of the connection is one who is 372 authorized to access local resources rather than someone who happened 373 upon an unoccupied but otherwise authorized system, or a malicious 374 trojan horse application on that user's system, or some other 375 unauthorized entity. Authenticating the user presents different 376 requirements than authenticating the user's machine; this requires 377 some form of user input, and often the authentication must be 378 periodically renewed. 380 In situations where a high level of physical security does not exist, 381 it is common to require a user-input secret as part of the 382 authentication process, and then to periodically renew the 383 authentication. Furthermore, since such circumstances may include the 384 possibility of the presence of a trojan horse application on the IRAC 385 system, one-time passphrase mechanisms are often advisable. Choosing 386 passphrase mechanisms and renewal intervals which provide an 387 acceptable level of risk, but which do not annoy the user too much, 388 may be challenging. It should be obvious that even this approach 389 offers limited assurance in many cases. 391 Clearly, there are variable assurance levels which are attainable 392 with the various endpoint authentication techniques, and none of the 393 techniques discussed offer absolute assurance. Also, there are 394 variations in the authentication requirements among different remote 395 access scenarios. This means there is no "cookie cutter" solution for 396 this problem, and that individual scenarios must be carefully 397 examined in order to derive specific requirements for each. These are 398 examined on a case by case basis below in the detailed scenario 399 descriptions. 401 2.1.5 Compatibility With Legacy Remote Access Mechanisms 403 There are a number of currently deployed remote access mechanisms 404 which were installed prior to the deployment of IPsec. Typically, 405 these are dialup systems which rely upon RADIUS for user 406 authentication and accounting, but there are other mechanisms as 407 well. An ideal IPsec remote access solution might utilize the 408 components of the underlying framework without modification. Inasmuch 409 as this is possible, this should be a goal. However, there may be 410 cases where this simply cannot be accomplished, due to security 411 and/or other considerations. In such cases, the IPsec remote access 412 framework should be designed to accommodate migration from these 413 mechanisms as painlessly as is possible. 415 In general, proposed IPsec remote access mechanisms should meet the 416 following goals: 418 o should provide direct support for legacy user authentication 419 and accounting systems such as RADIUS 421 o should encourage migration from existing low-entropy 422 password-based systems to more secure authentication systems 424 o if legacy user authentication support cannot be provided without 425 some sort of migration, the impact of such migration should be 426 minimized 428 o user authentication information must be protected against 429 eavesdropping and replay (including the user identity) 431 o single sign-on capability should be provided in configurations 432 employing load-balancing and/or redundancy 434 o n-factor authentication mechanisms should be supported 436 2.2 Remote Host Configuration 438 Remote host configuration refers to the network-related device 439 configuration of the client system. This configuration may be fixed 440 or dynamic. It may be completely provided by the administrator of the 441 network upon which the remote user currently resides (e.g. the ISP), 442 or it may be partially provided by that administrator, with the 443 balance provided by an entity on the remote corporate network which 444 the client is accessing. In general, this configuration may include 445 the following: 447 o IP address(es) 448 o Subnet mask(s) 449 o Broadcast address(es) 450 o Host name 451 o Domain name 452 o Time offset 453 o Servers (e.g. SMTP, POP, WWW, DNS/NIS, LPR, 454 syslog, WINS, NTP, etc. ) 455 o Router(s) 456 o Router discovery options 457 o Static routes 458 o MTU 459 o Default TTL 460 o Source routing options 461 o IP Forwarding enable/disable 462 o PMTU options 463 o ARP cache timeout 464 o X Windows options 465 o NIS options 466 o NetBIOS options 467 o Vendor-specific options 468 o (other options) 470 Cases where such configuration is fixed are uninteresting; it is the 471 cases where specific IRAC configuration occurs as a result of remote 472 access with which we are concerned. For example, in some cases the 473 IRAC may be assigned a "virtual address", giving the appearance that 474 it resides on the target network: 476 target net 477 +------------------+ | 478 | Remote Access | +--------+ | ( ~ ~ ~ ~ ~ ) 479 |+-------+ Client | | | | ( IRAC ) 480 ||virtual| | |security| |~~~( virtual ) 481 || host | |--------|gateway | | ( presence ) 482 || |<================>| |----| ~ ~ ~ ~ ~ 483 |+-------+ |--------| | | 484 +------------------+ ^ +--------+ | +--------+ 485 | |---| local | 486 IPsec tunnel | | host | 487 with encapsulated | +--------+ 488 traffic inside 490 In this case, the IRAC system begins with an externally routable 491 address. An additional target network address is assigned to the 492 IRAC, and packets containing this assigned address are encapsulated, 493 with the outer headers containing the IRAC's routable address, and 494 forwarded to the IRAS through the tunnel. This provides the IRAC with 495 a virtual presence on the target network via an IPsec tunnel. Note 496 that the IRAC now has two active addresses: the ISP-assigned address, 497 and the VIP. 499 Having obtained this virtual presence on the corporate network, the 500 IRAC may now require other sorts of topology-related configuration, 501 e.g. default routers, DNS server(s), etc., just as a dynamically 502 configured host which physically resides upon the target network 503 would. It is this sort of configuration with which this requirements 504 category is concerned. 506 2.3 Security Policy Configuration 508 Security policy configuration refers to IPsec access policies for 509 both the remote access client and the security gateway. It may be 510 desirable to configure access policies on connecting IRAC systems 511 which will protect the target network. For example, since a client 512 has access to the Internet (via its routable address), other systems 513 on the Internet also have some level of reciprocal access to the 514 client. In some cases, it may be desirable to block this Internet 515 access (or force it to pass through the tunnel) while the client has 516 a tunneled connection to the target network. This is a matter of 517 client security policy configuration. 519 For the security gateway, it may also be desirable to dynamically 520 adjust policies based upon the user with which a connection has been 521 established. For example, say there are two remote users, named Alice 522 and Bob. We wish to provide Alice with unrestricted access to the 523 target network, while we wish to restrict Bob's access to specific 524 segments. One way to accomplish this would be to statically assign 525 internal "virtual" addresses to each user in a one-to-one mapping, so 526 that each user always has the same address. Then, a particular user's 527 access could be controlled via policies based upon the particular 528 address. However, this does not scale well. 530 A more scalable solution for remote client access control would be to 531 dynamically assign IP addresses from a specific pool based upon the 532 authenticated endpoint identity, with access to specific resources 533 controlled by address-based policies in the SGW. This is very similar 534 to the static mapping described above, except that a given group of 535 users (those with identical access controls) would share a given pool 536 of IP addresses (those which are granted the required access), rather 537 than a given user always mapping to a given address. However, this 538 also has scaling issues, though not as pronounced as for the static 539 mapping. 541 Alternatively, an arbitrary address could be assigned to a user, with 542 the security gateway's policy being dynamically updated based upon 543 the identity of the remote client (and its assigned virtual address) 544 to permit access to particular resources. In these cases, the 545 relevant security policy configuration is specific to the IRAS, 546 rather than to the IRAC. Both IRAS and IRAC security policy 547 configuration are encompassed by this requirements category. 549 2.4 Auditing 551 Auditing is used here to refer to the collection and reporting of 552 connection status information by the IRAS, for the purpose of 553 maintaining the security and integrity of the network the IRAS 554 protects. For remote access, the following auditing information is 555 useful from a security perspective: 557 o connection start time 558 o connection end time 560 Note that the requirement for a connection-end-time attribute implies 561 the need for a connection heartbeat mechanism of some sort so that 562 the IRAS can accurately determine this quantity in cases where the 563 IRAC does not explicitly terminate the connection. Also note that the 564 heartbeat mechanism in this case is always directed from the IRAC to 565 the IRAS. 567 In some cases, use of a heartbeat may negatively influence a 568 connection. For example, if the heartbeat interval is very short, and 569 the connection is reset after loss of very few heartbeat packets, 570 there is a possibility that network congestion could lead to 571 unnecessary connection resets. The heartbeat interval and reset 572 threshold should be chosen with this in mind, and it should be 573 possible to adjust these quantities either through configuration or 574 negotiation. 576 2.5 Intermediary Traversal 578 Intermediary traversal is used here to refer to passing a secured 579 data stream through an intermediary such as a firewall or NAPT 580 device. In the case of firewalls, numerous deployed products do not 581 recognize the IPsec protocol suite, making it difficult (sometimes 582 impossible) to configure them to pass it through. In such cases, a 583 mechanism is required for making the data stream appear to be of a 584 type which the firewall is capable of managing. 586 In the case of NAPT devices, there are a number of issues with 587 attempting to pass an encrypted or authenticated data stream. For 588 example, NAPT devices typically modify the source IP address and 589 UDP/TCP port of outgoing packets, and the destination IP address and 590 UDP/TCP port of incoming packets, and in some cases, they modify 591 additional fields in the data portion of the packet. Such 592 modifications render the use of the AH protocol impossible. In the 593 case of ESP, the UDP/TCP port fields fields are sometimes unreadable 594 and always unmodifiable, making meaningful translation by the NAPT 595 device impossible. There are numerous other protocol-field 596 combinations which suffer similarly. This requirements category is 597 concerned with these issues. 599 3. Scenarios 601 There are numerous remote access scenarios possible using IPsec. This 602 section contains a brief summary enumeration of these, followed by a 603 subsection devoted to each which explores the various requirements in 604 terms of the categories defined above. 606 The following scenarios are discussed: 608 o dialup/dsl/cablemodem telecommuters using their 609 systems to access remote resources 611 o extranet users using local corporate systems to 612 access the remote company network of a business partner 614 o extranet users using their own system within another 615 company's network to access their home corporate network 617 o extranet users using a business partner's system (located 618 on that partner's network) to access their home corporate 619 network 621 o remote users using a borrowed system (e.g. an airport 622 kiosk) to access target network resources 624 3.1 Telecommuters (Dialup/DSL/Cablemodem) 626 The telecommuter scenario is one of the more common remote access 627 scenarios. The convenience and wide availability of Internet access 628 makes this an attractive option under many circumstances. Users may 629 access the Internet from the comfort of their homes or hotel rooms, 630 and using this Internet connection, access the resources of a target 631 network. In some cases, dialup accounts are used to provide the 632 initial Internet access, while in others some type of "always-on" 633 connection such as a DSL or CATV modem is used. 635 The dialup and always-on cases are very similar, with two significant 636 differences: address assignment mechanism, and connection duration. 637 In most dialup cases, the IRAC's IP address is dynamically assigned 638 as part of connection setup, and with fairly high likelihood, it is 639 different each time the IRAC connects. DSL/CATV users, on the other 640 hand, often have static IP addresses assigned to them, although 641 dynamic assignment is on the increase. As for connection duration, 642 dialup remote access connections are typically short-lived, while 643 always-on connections may maintain remote access connections for 644 significantly longer periods of time. 646 The general configuration in either case looks like this: 648 corporate net 650 | +----+ 651 +-----+ +-----+ /---/ Internet +---+ |--| | 652 |IRAC |---|modem|------|ISP|==========|SGW|--| +----+ 653 +-----+ +-----+ /---/ +---+ | 654 | 656 An alternative to this configuration entails placing a security 657 gateway between the user's system and the modem, in which case this 658 added SGW becomes the IRAC. This is currently most common in cases 659 where DSL/CATV connections are used. 661 3.1.1 Endpoint Authentication Requirements 663 The authentication requirements of this scenario depend in part upon 664 the general security requirements of the network to which access is 665 to be provided. Assuming that the corporate SGW is physically secure, 666 machine authentication for the SGW is sufficient. If this assumption 667 regarding physical security is incorrect, it is not clear that 668 stronger authentication for the SGW could be guaranteed, and 669 derivation of an effective mechanism for that case is beyond the 670 scope of this document. 672 For the IRAC, there are numerous threats to the integrity of the user 673 authentication process. Due to the open nature of common consumer 674 operating systems, some of these threats are quite difficult to 675 protect against. For example, it is very difficult to assert with any 676 level of certainty that a single user system which permits the 677 downloading and running of arbitrary applications from the Internet 678 has not been compromised, and that a covert application is not 679 monitoring and interacting with the user's data at any point in time. 681 However, there are 2 general threats we might realistically hope to 682 somehow mitigate with appropriate authentication mechanisms if we can 683 assume that the system has not been compromised in this manner. 684 First, there is the possibility that a secure connection is 685 established for a particular user, but that someone other than the 686 intended user is currently using that connection. Second, there is 687 the possibility that the user's credential (password, hardware token, 688 etc.) has been somehow compromised, and is being used by someone 689 other than the authorized user to gain access. 691 Mitigation of the first threat, the possibility that someone other 692 than the authorized user is currently using the connection, requires 693 periodic renewal of user authentication. It should be clear that 694 machine authentication will not suffice in this case, and that 695 requiring periodic re-entry of an unchanging user password (which may 696 be written on a post-it note which is stuck to the user's monitor) 697 will have limited effectiveness. Convincing verification of the 698 continued presence of the authorized user will, in many cases, 699 require periodic application of a time-variant credential. 701 Mitigation of the second threat, credential compromise, is difficult, 702 and depends upon a number of factors. If the IRAC system is running a 703 highly secure operating system, then a time-variant credential may 704 again offer some value. A static password is clearly deficient in 705 this scenario, since it may be subject to either online or offline 706 guessing, and eventually compromised - which is the threat we are 707 attempting to mitigate. However, if the IRAC operating system is not 708 hardened, the use of a time-variant credential is only effective if 709 simultaneous access from more than one location is forbidden, and if 710 the credential generation mechanism is not easily compromised. 712 A second approach to the credential compromise problem entails using 713 a PKI-based credential which is stored within a secure container of 714 some sort, and which requires some user interaction prior to 715 operation (e.g. a smartcard). If such a credential requires periodic 716 user interaction to continue operating (e.g. pin re-entry), this may 717 help to limit the access of an unauthorized user who happens upon a 718 connected but unattended systems. However, choosing an acceptable 719 refresh interval is a difficult problem, and if the pin is not time- 720 variant, this provides limited additional assurance. 722 To summarize, the following are the authentication requirements for 723 the IRAS and IRAC: 725 IRAS 726 ---- 728 o machine authentication MUST be provided. 730 IRAC 731 ---- 733 o support for user authentication SHOULD be provided 734 o support for either user or machine authentication MUST 735 be provided 736 o support for user authentication MUST be provided if 737 protection from unauthorized connection use is desired. 738 o if user authentication is provided for short-lived dialup 739 connections, periodic renewal MAY occur 740 o if user authentication is provided for always-on connections, 741 periodic renewal SHOULD occur 743 3.1.2 Device Configuration Requirements 745 There are 2 possibilities for device configuration in the 746 telecommuter scenario: either access to the target network is 747 permitted for the native ISP-assigned address of the telecommuter's 748 system, or the telecommuter's system is assigned a virtual address 749 from within the target address space. In the first case, there are no 750 device configuration requirements which are not already satisfied by 751 the ISP. However, this case is the exception, rather than the rule. 753 The second case is far more common, due to the numerous benefits 754 derived by providing the IRAC with a virtual presence on the target 755 network. For example, the virtual presence allows the client to 756 receive subnet broadcasts, which permits it to use WINS on the target 757 network. In addition, if the IRAC tunnels all traffic to the target 758 network, then the target policy can be applied to Internet traffic 759 to/from the IRAC. 761 In this case, the IRAC requires, at minimum, assignment of an IP 762 address from the target network. Typically, the IRAC requires 763 anywhere from several more to many more elements of configuration 764 information, depending upon the corporate network's level of 765 topological complexity. For a fairly complete list, see section 2.2. 767 To summarize, the following are the device configuration requirements 768 for the IRAC: 770 o support for a virtual IP (VIP) address MAY be provided 771 o if VIP support is provided, support for all device-related 772 parameters listed in section 2.2 above SHOULD be provided 773 o support for address assignment based upon authenticated 774 identity MAY be provided 775 o if authenticated address assignment is not supported, an 776 identity-based dynamic policy update mechanism such as 777 is described in [ARCH] MUST be supported. 779 3.1.3 Policy Configuration Requirements 781 In terms of IRAC policy configuration, the most important issue 782 pertains to whether the IRAC has direct Internet access enabled (for 783 browsing, etc.) while a connection to the target network exists. 784 This is important since the fact that the IRAC has access to sites on 785 the Internet implies that those sites have some level of reciprocal 786 access to the IRAC. It may be desirable to completely eliminate this 787 type of access while a tunnel is active. 789 Alternatively, the risks may be mitigated somewhat by forcing all 790 Internet-bound packets leaving the IRAC to first traverse the tunnel 791 to the target network, where they may be subjected to target network 792 policy. A second approach which carries a bit less overhead entails 793 modifying the IRAC's policy configuration to reflect that of the 794 target network during the time the IRAC is connected. In this case, 795 traffic is not forced to loop through the target site prior to 796 exiting or entering the IRAC. This requires some sort of policy 797 download (or modification) capability as part of the SA establishment 798 process. A third approach is to provide a configuration variable for 799 the IRAC which permits specification of "tunnel-all", or "block all 800 traffic not destined for the target network while the SA is up". 802 In terms of IRAS configuration, it may be necessary to dynamically 803 update the security policy database (SPD) when the remote user 804 connects. This is because transit selectors must be based upon 805 network address parameters, but these cannot be known a priori in the 806 remote access case. As is noted above, this may be avoided by 807 provision of a mechanism which permits address assignment based upon 808 authenticated identity. 810 To summarize, the following are the policy configuration requirements 811 for the IRAS and IRAC: 813 IRAS 814 ---- 816 o dynamic policy update mechanism based upon identity and 817 assigned address MAY be supported. 819 o if address assignment-based policy update mechanism is 820 not supported, address assignment based upon authenticated 821 identity SHOULD be supported. 823 IRAC 824 ---- 826 o IRAC SHOULD provide ability to configure for "tunnel-all" 827 and/or "block-all" for traffic not destined for the 828 remote network to which IPsec remote access is being 829 provided. 831 o support for dynamic IRAS update of IRAC policy MAY be provided. 833 3.1.4 Auditing Requirements 835 For telecommuter sessions, session start/end times must be collected. 836 Reliable derivation of session end time requires that the IRAC 837 somehow periodically signify that the connection remains active. This 838 is implied if the IRAS receives data from the IRAC over the 839 connection, but in cases where no data is sent for some period of 840 time, a signaling mechanism is required by which the IRAC indicates 841 that the connection remains in use. 843 3.1.5 Intermediary Traversal Requirements 845 If the address assigned by the ISP to the IRAC system is globally 846 routable, and no intermediate devices between the IRAC and the IRAS 847 perform NAPT operations on the data stream, then there are no 848 additional requirements. If NAPT operations are performed on the 849 data stream, some mechanism must be provided in order to render these 850 modifications transparent to the IPsec implementation. 852 3.2 Corporate to Remote Extranet 854 Extranets are becoming increasingly common, especially as IPsec 855 becomes more widely deployed. In this scenario, a user from one 856 corporation uses a local corporate system to access resources on 857 another corporation's network. Typically, these corporations are 858 cooperating on some level, but not to the degree that unbridled 859 access between the two networks would be acceptable. Hence, this 860 scenario is characterized by limited access. The general topological 861 appearance is similar to this: 863 CORP A CORP B 864 | | 865 +----+ | | +-----+ 866 |USER|---| |--| S1 | 867 +----+ | +------++ ++------+ | +-----+ 868 |---|SGW/FW||===Internet===||SGW/FW|---| 869 | +------++ ++------+ | +-----+ 870 | SGW-A SGW-B |--| S2 | 871 | | +-----+ 873 This is purposely simplified in order to illustrate some basic 874 characteristics without getting bogged down in details. At the edge 875 of each network is a combination security gateway and firewall 876 device. These are labeled "SGW-A" and "SGW-B". In this diagram, 877 corporation B wishes to provide a user from corporation A with access 878 to servers S1 and/or S2. This may be accomplished in one of several 879 different ways: 881 1) an end-to-end SA is formed from USER to S1 or S2 883 2) a tunnel-mode SA is formed between SGW-A and SGW-B which only 884 permits traffic between S1/S2 and USER. 886 3) a tunnel-mode SA is formed between USER and SGW-B which only 887 permits traffic between S1/S2 and USER. 889 These various cases are individually discussed with respect to each 890 requirements category below. 892 3.2.1 Authentication Requirements 894 For the corporate extranet scenario, the authentication requirements 895 vary slightly depending upon the manner in which the connection is 896 accomplished. If only a particular user is permitted to access S1/S2, 897 then user-level authentication is required. If connection types (1) 898 or (3) are used, this may be accomplished in the same manner as it 899 would be for a telecommuter. If connection type (2) is used, one of 900 two things must occur: either SGW-A must provide some local mechanism 901 for authenticating USER and SGW-B must trust this mechanism, or SGW-B 902 must have some mechanism for authenticating USER independently of 903 SGW-A. 905 If access is permitted for anyone within corporation A, then machine 906 authentication will suffice. However, this is highly unlikely. A 907 slightly more likely situation might be one in which access is 908 permitted to anyone within a particular organizational unit in 909 corporation A. This case is very similar the single user access case 910 discussed above, and essentially has the same requirements in terms 911 of the mechanism required for SGW-A, although machine authentication 912 might suffice if the organizational unit which is permitted access 913 has a sufficient level of physical security. Again, this requires 914 that corporation B trust corporation A in this regard. 916 To summarize, the following are the authentication requirements for 917 the IRAS and IRAC: 919 IRAS 920 ---- 922 o machine authentication MUST be provided. 924 IRAC 925 ---- 927 o support for either user or machine authentication MUST 928 be provided 929 o support for a combination of user and machine authentication 930 SHOULD be provided 931 o if user authentication is used, periodic renewal SHOULD occur 933 3.2.2 Device Configuration Requirements 935 It is possible that corporation B would want to assign a virtual 936 address to USER for the duration of the connection. The only way this 937 could be accomplished would be if USER were a tunnel endpoint (e.g. 938 in cases (1) and (3)). It is not clear what benefits, if any, this 939 would offer. 941 To summarize, the following are the device configuration requirements 942 for the IRAC: 944 o support for a virtual address MAY be provided 945 o if VIP support is provided, support for all device-related 946 parameters listed in section 2.2 above SHOULD be supported 947 o support for address assignment based upon authenticated 948 identity SHOULD be supported 949 o if authenticated address assignment is not supported, an 950 identity-based dynamic policy update mechanism such as 951 is described in [ARCH] MUST be supported. 953 3.2.3 Policy Configuration Requirements 955 Any of the cases discussed above would present some static policy 956 configuration requirements. Case (1) would require that SGW-A and 957 SGW-B permit IPsec traffic to pass between USER and S1/S2. Case (3) 958 would have similar requirements, except that the IPsec traffic would 959 be between USER and SGW-B. Case (2) would require that the 960 appropriate transit traffic be secured between USER and S1/S2. 962 None of these cases require dynamic policy configuration. 964 3.2.4 Auditing Requirements 966 For cases (1) and (3), session start/end times must collected. 967 Reliable derivation of session end time requires that the IRAC 968 somehow periodically signify that the connection remains active. This 969 is implied if the IRAS receives data from the IRAC over the 970 connection, but in cases where no data is sent for some period or 971 time, a signaling mechanism is required by which the IRAC indicates 972 that the connection remains in use. 974 For case (2), the type(s) of required auditing data would depend upon 975 whether traffic from multiple users were aggregated within a single 976 tunnel or not. If so, the notion of individual connection start/stop 977 times would be lost. If such measures are desired, this requires that 978 per-user tunnels be set up between SGW-A and SGW-B, and that some 979 sort of timeout interval be used to cause tunnel teardown when 980 traffic does not flow for some interval of time. 982 3.2.5 Intermediary Traversal Requirements 984 If the address assigned by the host network to the IRAC system is 985 globally routable, and no intermediate devices between the IRAC and 986 the IRAS perform NAPT operations on the data stream, then there are 987 no additional requirements in this regard. If NAPT operations are 988 performed on the data stream, some mechanism must be provided in 989 order to render these modifications transparent to the IPsec 990 implementation. 992 If a firewall situated at the edge of the host network cannot be 993 configured to pass protocols in the IPsec suite, then some mechanism 994 must be provided which converts the data stream to one which the 995 firewall may be configured to pass. If the firewall can be 996 configured to pass IPsec protocols, then this must be accomplished 997 prior to connection establishment. 999 3.3 Extranet Laptop to Home Corporate Net 1001 The use of a laptop while visiting another corporation presents 1002 another increasingly common extranet scenario. In this case, a user 1003 works temporarily within another corporation, perhaps as part of a 1004 service agreement of some sort. The user brings along a CORP-A laptop 1005 which is assigned a CORP-B address either statically or dynamically, 1006 and the user wishes to securely access resources on CORP-A's network 1007 using this laptop. This scenario has the following appearance: 1009 CORP A CORP B 1010 | | 1011 +----+ | | +--------+ 1012 |POP |---| |--| CORP-A | 1013 +----+ | +------++ ++------+ | | laptop | 1014 |---|SGW/FW||===Internet===||SGW/FW|---| +--------+ 1015 | +------++ ++------+ | 1016 +----+ | SGW-A SGW-B | 1017 |FTP |---| | 1018 +----+ | | 1020 This is very similar to the telecommuter scenario, but it differs in 1021 several important ways. First, in this case there is often a SGW 1022 and/or firewall at the edge of CORP-B's site. Second, there may be a 1023 significantly increased risk that a long-lived connection could 1024 become accessible to someone other than the intended user. 1026 3.3.1 Authentication Requirements 1028 In most cases, the only acceptable connections from CORP-A's 1029 perspective are between the laptop and either SGW-A or the CORP-A 1030 servers the laptop wishes to access. Most of the considerations 1031 applied to the telecommuter also apply here, and user-level 1032 authentication is required to provide assurance that the user who 1033 initiated the connection is still the active user. As an added 1034 precaution, a combination of user-level and machine-level 1035 authentication may be warranted in some cases. Further, in either 1036 case this authentication should be renewed frequently. 1038 To summarize, the following are the authentication requirements for 1039 the IRAS and IRAC: 1041 IRAS 1042 ---- 1044 o machine authentication MUST be provided. 1046 IRAC 1047 ---- 1049 o support for machine authentication SHOULD be provided 1050 o support for user authentication MUST be provided 1051 o support for a combination of user and machine authentication 1052 SHOULD be provided 1053 o periodic renewal of user authentication MUST occur 1055 3.3.2 Device Configuration Requirements 1057 The device configuration requirements in this scenario are the same 1058 as for the telecommuter, i.e. the laptop may be assigned a virtual 1059 presence on the corporate network, and if so, will require full 1060 infrastructure configuration. 1062 To summarize, the following are the device configuration requirements 1063 for the IRAC: 1065 o support for a virtual address MAY be provided 1066 o if VIP support is provided, support for all device-related 1067 parameters listed in section 2.2 above SHOULD be supported 1068 o support for address assignment based upon authenticated 1069 identity SHOULD be supported 1070 o if authenticated address assignment is not supported, an 1071 identity-based dynamic policy update mechanism such as 1072 is described in [ARCH] MUST be supported. 1074 3.3.3 Policy Configuration Requirements 1076 The policy configuration requirements in this scenario differ from 1077 those of the telecommuter, in that the laptop cannot be assigned a 1078 policy which requires all traffic to be forwarded to CORP-A via the 1079 tunnel. This is due to the fact that the laptop has a CORP-B address, 1080 and as such, may have traffic destined to CORP-B. If this traffic 1081 were tunneled to CORP-A, there might be no return path to CORP-B 1082 except via the laptop. On the other hand, Internet-bound traffic 1083 could be subjected to this restriction if desired, and/or all traffic 1084 other than that between CORP-A and the laptop could be blocked for 1085 the duration of the connection. 1087 IRAC 1088 ---- 1090 o support for IRAS update of IRAC policy MAY be provided. 1092 o if IRAS update of IRAC policy is not supported, IRAC MAY 1093 support IRAS directives to "block-all" for non-tunneled 1094 traffic. 1096 o IRAC SHOULD provide ability to configure for "tunnel-all" 1097 and/or "block-all" for traffic not destined for the 1098 remote network to which IPsec remote access is being 1099 provided. 1101 3.3.4 Auditing Requirements 1103 The auditing requirements in this scenario are the same as for the 1104 telecommuter scenario. Session start/end times must collected. 1105 Reliable derivation of session end time requires that the IRAC 1106 somehow periodically signify that the connection remains active. 1107 This is implied if the IRAS receives data from the IRAC over the 1108 connection, but in cases where no data is sent for some period or 1109 time, a signaling mechanism is required by which the IRAC indicates 1110 that the connection remains in use. 1112 3.3.5 Intermediary Traversal Requirements 1114 If the address assigned by the host network to the IRAC system is 1115 globally routable, and no intermediate devices between the IRAC and 1116 the IRAS perform NAPT operations on the data stream, then there are 1117 no additional requirements in this regard. If NAPT operations are 1118 performed on the data stream, some mechanism must be provided in 1119 order to render these modifications transparent to the IPsec 1120 implementation. 1122 If a firewall situated at the edge of the host network cannot be 1123 configured to pass protocols in the IPsec suite, then some 1124 mechanism must be provided which converts the data stream to one 1125 which the firewall may be configured to pass. If the firewall can 1126 be configured to pass IPsec protocols, then this must be 1127 accomplished prior to connection establishment. 1129 3.4 Extranet Desktop to Home Corporate Net 1131 This is very similar to the extranet laptop scenario discussed above, 1132 except that a higher degree of trust for CORP-B is required by CORP- 1133 A. This scenario has the following appearance: 1135 CORP A CORP B 1136 | | 1137 +----+ | | +--------+ 1138 |POP |---| |--| CORP-B | 1139 +----+ | +------++ ++------+ | |desktop | 1140 |---|SGW/FW||===Internet===||SGW/FW|---| +--------+ 1141 | +------++ ++------+ | 1142 +----+ | SGW-A SGW-B | 1143 |FTP |---| | 1144 +----+ | | 1146 3.4.1 Authentication Requirements 1148 The authentication requirements for the desktop extranet scenario are 1149 very similar to those of the extranet laptop scenario discussed 1150 above. The primary difference lies in the authentication type which 1151 may be used, i.e. in the laptop case, CORP-A can derive some 1152 assurance that the connection is coming from one of CORP-A's systems 1153 if a securely stored machine credential is stored on and used by on 1154 the laptop. In the desktop case this is not possible, since CORP-A 1155 does not own the IRAC system. 1157 To summarize, the following are the authentication requirements for 1158 the IRAS and IRAC: 1160 IRAS 1161 ---- 1163 o machine authentication MUST be provided. 1165 IRAC 1166 ---- 1167 o support for machine authentication MAY be provided 1168 o support for user authentication MUST be provided 1169 o support for a combination of user and machine authentication 1170 MAY be provided 1171 o periodic renewal of user authentication MUST occur 1173 3.4.2 Device Configuration Requirements 1175 The device configuration requirements in this scenario are the same 1176 as for the laptop extranet scenario, i.e. the desktop system may be 1177 assigned a virtual presence on the corporate network, and if so, 1178 will require full infrastructure configuration. However, this seems 1179 less likely than in the laptop scenario, given CORP-A's lack of 1180 control over the software configuration of CORP-B's desktop system. 1182 3.4.3 Policy Configuration Requirements 1184 The policy configuration requirements are quite similar to those of 1185 the extranet laptop, except that in this scenario there is even 1186 less control over CORP-B's desktop than there would be over the 1187 laptop. This means it may not be possible to restrict traffic in 1188 any way at the desktop system. 1190 3.4.4 Auditing Requirements 1192 The auditing requirements in this scenario are the same as for the 1193 telecommuter scenario. Session start/end times must collected. 1194 Reliable derivation of session end time requires that the IRAC 1195 somehow periodically signify that the connection remains active. 1196 This is implied if the IRAS receives data from the IRAC over the 1197 connection, but in cases where no data is sent for some period or 1198 time, a signaling mechanism is required by which the IRAC indicates 1199 that the connection remains in use. 1201 3.4.5 Intermediary Traversal Requirements 1203 If the address assigned by the host network to the IRAC system is 1204 globally routable, and no intermediate devices between the IRAC and 1205 the IRAS perform NAPT operations on the data stream, then there are 1206 no additional requirements in this regard. If NAPT operations are 1207 performed on the data stream, some mechanism must be provided in 1208 order to render these modifications transparent to the IPsec 1209 implementation. 1211 If a firewall situated at the edge of the host network cannot be 1212 configured to pass protocols in the IPsec suite, then some 1213 mechanism must be provided which converts the data stream to one 1214 which the firewall may be configured to pass. If the firewall can 1215 be configured to pass IPsec protocols, then this must be 1216 accomplished prior to connection establishment. 1218 3.5 Public System to Target Network 1220 This scenario entails a traveling user connecting to the target 1221 network using a public system owned by someone else. A commonly 1222 cited example is an airport kiosk. This looks very similar to the 1223 extranet desktop scenario, except that in the extranet scenario, 1224 CORP-A might have a trust relationship with CORP-B, whereas in this 1225 scenario, CORP-A may not trust a publically accessible system. Note 1226 that a trust relationship between CORP-A and the owner of the 1227 public system may exist, but in many cases will not. 1229 3.5.1 Authentication Requirements 1231 There are two variations to this scenario. In the first, no trust 1232 relationship exists between the target network and the borrowed 1233 system. In the second, some trust relationship does exist. In the 1234 case where no trust relationship exists, machine authentication is 1235 out of the question, as it is meaningless in this context. Further, 1236 since such a system could easily capture a passphrase, use of a 1237 static passphrase from such a system would seem to be ill-advised. 1239 If a one-time passphrase were used, this would mitigate the risk of 1240 passphrase capture by the public system. On the other hand, if it 1241 is acknowledged that such capture is a real threat (i.e. the system 1242 itself is malicious), then it must also be recognized that any data 1243 transmitted and received via the resulting session would not be 1244 confidential or reliable with respect to this malicious system, and 1245 that the system could not be trusted to have actually disconnected 1246 when the user walks away. This suggests that accessing non-trivial 1247 information from such a system would be imprudent. 1249 Another possible user authentication option would be a smartcard. 1250 However, many smartcards require a pin or passphrase to "unlock" 1251 them, which requires some level of trust in the kiosk to not record 1252 the pin. Hence, this approach suffers from drawbacks similar to 1253 those of the static passphrase in this regard. The primary 1254 difference would be that the pin/passphrase could not be used alone 1255 for access in the smartcard case. 1257 In cases where a trust relationship with the owner of the public 1258 system exists, the trust level would modulate the risk levels 1259 discussed above. For example, if a sufficient level of trust for 1260 the system owner exists, use of a static passphrase might present 1261 no more risk than if this were permitted from a system owned by the 1262 accessed target. However, the primary benefit of such a trust 1263 relationship would be derived from the ability to authenticate the 1264 machine from which the user is attempting access. For example, a 1265 security policy requiring that remote access only be permitted with 1266 combined user/machine authentication might be effected, with 1267 further control regarding which machines were allowed. 1269 An additional issue to be dealt with in either case pertains to 1270 verification of the identity of the IRAS. If the IRAC were to be 1271 misdirected somehow, a man in the middle attack could be effected, 1272 with the obtained password being then used for malicious access to 1273 the true IRAS. Note that even a one-time password mechanism offers 1274 little protection in this case. In order to avert such an attack, 1275 the IRAC must possess some certifiable or secret knowledge of the 1276 IRAS prior to attempting to connect. Note that in the case where no 1277 trust relationship exists, this is not possible. 1279 To summarize, the following are the authentication requirements for 1280 the IRAS and IRAC: 1282 IRAS 1283 ---- 1285 o machine authentication MUST be provided. 1287 IRAC 1288 ---- 1290 o in cases where no trust relationship exists between the 1291 accessed network and the system owner, sensitive data 1292 SHOULD NOT be transmitted in either direction. 1293 o in cases where a trust relationship exists between the 1294 accessed network and the system owner, machine authentication 1295 SHOULD be supported. 1296 o in cases where a trust relationship exists between the 1297 accessed network and the system owner, a static passphrase 1298 MAY be used in conjunction with machine-level authentication 1299 of the IRAC system. 1300 o frequent renewal of user authentication MUST occur 1302 3.5.2 Device Configuration Requirements 1304 None. 1306 3.5.3 Policy Configuration Requirements 1308 None. 1310 3.5.4 Auditing Requirements 1312 The auditing requirements in this scenario are the same as for the 1313 telecommuter scenario. Session start/end times must collected. 1314 Reliable derivation of session end time requires that the IRAC 1315 somehow periodically signify that the connection remains active. 1316 This is implied if the IRAS receives data from the IRAC over the 1317 connection, but in cases where no data is sent for some period of 1318 time, a signaling mechanism is required by which the IRAC indicates 1319 that the connection remains in use. 1321 3.5.5 Intermediary Traversal Requirements 1323 If the address of the IRAC system is globally routable, and no 1324 intermediate devices between the IRAC and the IRAS perform NAPT 1325 operations on the data stream, then there are no additional 1326 requirements in this regard. If NAPT operations are performed on 1327 the data stream, some mechanism must be provided in order to render 1328 these modifications transparent to the IPsec implementation. 1330 4. Scenario Commonalities 1332 As we examine the various remote access scenarios, a general set of 1333 common requirements emerge. Following is a summary: 1335 o Support for user authentication is required in almost 1336 all scenarios 1338 o Machine authentication for the IRAS is required in all 1339 scenarios 1341 o A mechanism for providing device configuration for the 1342 IRAC is required in most scenarios. Such a mechanism must 1343 be extensible. 1345 o Machine authentication for IRAC is generally only useful 1346 when combined with user authentication. Combined user and 1347 and machine authentication is useful in some scenarios. 1349 o Dynamic IRAC policy configuration is useful in several 1350 scenarios. 1352 o Most scenarios require auditing for session start/stop 1353 times. 1355 o An intermediary traversal mechanism may be required in 1356 any of the scenarios. 1358 5. Security Considerations 1360 The topic of this document is secure remote access. Security 1361 considerations are discussed throughout the document. 1363 6. Editors' Addresses 1365 Scott Kelly 1366 RedCreek Communications 1367 3900 Newpark Mall Road 1368 Newark, CA 94560 USA 1369 email: skelly@redcreek.com 1370 Telephone: +1 (510) 745-3969 1372 Sankar Ramamoorthi 1373 Nexsi 1374 1959 Concourse Drive 1375 San Jose, CA 95131 USA 1376 E-mail: sankar@nexsi.com 1377 Telephone: +1 (408) 579-5718 1379 7. References 1381 [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the 1382 Internet Protocol", RFC 2401, November 1998. 1384 [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate 1385 Requirement Levels", BCP 14, RFC 2119, March 1997. 1387 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, 1388 "Remote Authentication Dial In User Service 1389 (RADIUS)", RFC2138 1391 [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange 1392 (IKE)", RFC 2409, November 1998. 1394 8. Acknowledgements 1396 The editors would like to acknowledge the many helpful comments of Sara 1397 Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and other 1398 members of the ipsra working group who have made helpful comments on this work. 1400 9. Full Copyright Statement 1402 Copyright (C) The Internet Society (2001). All Rights Reserved. 1404 This document and translations of it may be copied and furnished to 1405 others, and derivative works that comment on or otherwise explain it 1406 or assist in its implementation may be prepared, copied, published 1407 and distributed, in whole or in part, without restriction of any 1408 kind, provided that the above copyright notice and this paragraph 1409 are included on all such copies and derivative works. However, this 1410 document itself may not be modified in any way, such as by removing 1411 the copyright notice or references to the Internet Society or other 1412 Internet organizations, except as needed for the purpose of 1413 developing Internet standards in which case the procedures for 1414 copyrights defined in the Internet Standards process must be 1415 followed, or as required to translate it into languages other than 1416 English. 1418 The limited permissions granted above are perpetual and will not be 1419 revoked by the Internet Society or its successors or assigns. 1421 This document and the information contained herein is provided on an 1422 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1423 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1424 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1425 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1426 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1428 Appendix A: Change Log 1430 00 to 01: 1432 o delete mobility requirements 1433 o add accounting requirements 1434 o extensively modify discussion of endpoint authentication, and 1435 machine vs. user authentication 1436 o delete roaming/wireless users and user-to-user connections from 1437 Scenarios bullet list 1438 o Add discussion of trojan horse applications to telecommuter scenario 1439 o add statement about encouraging migration to PKI-based systems to 1440 legacy compatibility section. 1441 o clarified language in section 2.3 (Security Policy Configuration) 1442 01 to 02: 1444 o add n-factor authentication to general requirements 1445 o change "accounting" to "auditing" 1446 o delete incoming/outgoing octet counts from auditing requirements 1447 o added intermediary traversal requirements 1448 o numerous general edits for clarity 1450 02 to 03: 1452 o minor edits throughout 1453 o significantly modified introduction to provide discussion 1454 of L2TP/IPsec 1455 o replaced "corporate" with "target" when referring to the 1456 network the IRAS protects 1457 o modified discussion in section 3.1.1 1458 o changed SHOULD to MAY in section 3.2.2, support for address 1459 assignment based on authenticated identity 1461 03 to 04 1462 o minor edits throughout 1463 o removed discussion of L2TP/IPsec from introduction 1464 o changed some of the remaining "corporate" references 1465 to "target" 1466 o added "NAPT" to general terminology definitions 1467 o collapsed "road warrior" scenario into remote telecommuter 1468 scenario