idnits 2.17.1 draft-kelly-ipsra-userauth-00.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 abstract seems to contain references ([RFC2409], [RFC2138]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 486: '...work. These selectors MAY point to the...' RFC 2119 keyword, line 488: '... MAY require the instantiation o...' RFC 2119 keyword, line 490: '...to the proxy application MAY remain as...' RFC 2119 keyword, line 497: '...number of attempts, the client MUST be...' RFC 2119 keyword, line 565: '...ss, preshared keys SHOULD NOT be used....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 211 has weird spacing: '... the infra...' -- 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 section? 'RFC2026' on line 11 looks like a reference -- Missing reference section? 'RFC2409' on line 662 looks like a reference -- Missing reference section? 'RFC2138' on line 650 looks like a reference -- Missing reference section? 'GSS' on line 629 looks like a reference -- Missing reference section? 'RFC1661' on line 647 looks like a reference -- Missing reference section? 'RFC2284' on line 654 looks like a reference -- Missing reference section? 'XAUTH' on line 669 looks like a reference -- Missing reference section? 'RFC2119' on line 118 looks like a reference -- Missing reference section? 'HYBRID' on line 633 looks like a reference -- Missing reference section? 'ISACFG' on line 637 looks like a reference -- Missing reference section? 'SASL' on line 644 looks like a reference -- Missing reference section? 'RADIUSEXT' on line 640 looks like a reference -- Missing reference section? 'RFC2401' on line 658 looks like a reference -- Missing reference section? 'RFC2661' on line 665 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Scott Kelly, Jim Knowles 2 INTERNET-DRAFT RedCreek Communications 3 draft-kelly-ipsra-userauth-00.txt Bernard Aboba, Microsoft 4 Expires in 6 months October, 1999 6 User-level Authentication Mechanisms for IPsec 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 its working groups. Note that other groups may also 14 distribute 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 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Comments on this document should be sent to "ietf-ipsra@vpnc.org", 34 the IPsec remote access discussion list. 36 Abstract 38 IPsec, when used with IKE [RFC2409], provides for authentication of 39 endpoints from the device level to the user level. However, there has 40 been movement within the IPsec development community to provide 41 additional support for legacy user-level authentication mechanisms 42 such as those supported by RADIUS [RFC2138]. At least 2 approaches to 43 this problem have been proposed thus far, both using the same basic 44 underlying framework, but that underlying framework relies upon 45 extending IKE in ways that may not be prudent. This document 46 proposes an alternative approach which provides much of the same 47 functionality without requiring any modification to the existing 48 IPsec framework. 50 1. Introduction 52 IPsec, when used with IKE [RFC2409], provides for strong 53 authentication of endpoints from the device level to the user level. 54 The authentication methods supported range from preshared secrets to 55 X.509 certificates. The entity authenticated by these mechanisms may 56 be only the device, especially in cases where no user input is 57 required in order for the subject device to access the IKE 58 authentication credential. However, varying levels of user input may 59 be required to provide the device with access to the authentication 60 credential, in which case a single-factor or two-factor 61 authentication mechanism may be employed. 63 An example of a single-factor authentication mechanism which provides 64 relatively weak user-level authentication would be one in which the 65 user provides a password which is then used as a preshared key for 66 IKE authentication. A second example, perhaps slightly stronger, 67 might consist in the user plugging in a smartcard which contains the 68 authentication material (and perhaps applies it using an embedded 69 processor), but which does not require the user to somehow "unlock" 70 it. An example of strong two-factor authentication in this context 71 might be realized if the user were required to first plug in a smart 72 card containing the user's identity certificate, and then unlock that 73 card using a non-trivial challenge/response mechanism. Even this 74 mechanism has its limitations, depending upon one's level of 75 paranoia, but these limitations are not due to any shortcoming in 76 IPsec per se; rather, they are inherent in the nature of computer 77 security. 79 While numerous authentication mechanisms (including some very strong 80 ones) are currently supported by IPsec, there has been movement 81 within the IPsec development community to provide additional support 82 for legacy authentication mechanisms such as those supported with 83 RADIUS [RFC2138] and GSS_API [GSS]. RADIUS-supported mechanisms 84 include authentication methods supported in PPP [RFC1661], including 85 PAP, CHAP, and EAP [RFC2284]. Such support is generally viewed as a 86 necessary stepping stone to broad support for public key mechanisms. 88 The movement for legacy support has been especially concerned with 89 deployments supporting remote access, wherein users typically access 90 the resources of a corporate network from a remote location. In many 91 of these cases, other remote access mechanisms such as those 92 discussed above have been in use prior to the IPsec deployment, and 93 in such cases, the administrators of these deployments often wish to 94 continue using installed authentication and accounting mechanisms in 95 order to preserve their investment in these technologies and lessen 96 administrative costs. 98 At least 2 approaches to this problem have been proposed [XAUTH, 99 HYBRID], both using the same basic underlying framework, but 100 differing in otherwise substantial ways. However, the underlying 101 framework detailed in [XAUTH] relies upon extending IKE in ways that 102 may not be prudent. This document proposes an alternative approach 103 which provides much of the same functionality without requiring any 104 extension to the existing IPsec framework. 106 1.1 Reader Prerequisites 108 Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to 109 understanding the concepts discussed here. Familiarity with RADIUS, 110 L2TP, and PPP [RFC1661] will also be helpful, though not strictly 111 necessary. 113 1.2 Requirements Keywords 115 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 116 and "MAY" that appear in this document are to be interpreted as 117 described in [RFC2119]. 119 2. User-level Authentication 121 2.1 General considerations 123 In general, the motivation for extended authentication methods arises 124 from the network administrator's desire to authenticate the remote 125 user in a meaningful manner prior to providing access to valued 126 resources. While such functionality may ultimately be provided by a 127 reliable Public Key Infrastructure (PKI), such a PKI is not yet 128 widely deployed. As a result, many administrators providing remote 129 access desire IPsec support for the authentication and accounting 130 mechanisms which they currently utilize with other remote access 131 mechanisms. 133 In addition to the lack of ubiquitous PKI, there is other motivation 134 for continued support of existing mechanisms. While we might imagine 135 a future in which all computer users carry a hardware mechanism such 136 as a smart card, and in which all computer systems have peripheral 137 hardware capable of utilizing such mechanisms, this day may never 138 arrive. Regardless, cases will exist in which PK certificates are 139 somehow stored upon the system from which they are used. While these 140 certificates may be password (or otherwise) protected, there is 141 always the possibility that either the certificate access mechanism 142 has been compromised, or that the current session user is not the 143 user who initially provided access to the certificate. In these 144 cases, the end user is not authenticated; rather, the machine itself 145 has been authenticated. 147 As a matter of clarification, it is important to make a distinction 148 between authenticating a device and authenticating a user. In cases 149 where no user interaction is required in order for a device to form 150 an IKE security association with another system, it is clearly the 151 device which has been authenticated, and not the user. In cases where 152 user input is required which influences the authentication credential 153 selection or production process, some degree of user-level 154 authentication results. However, as noted above, this degree of 155 authentication may be dependent upon other factors, and may vary with 156 time. 158 Given the varying levels of user authentication which are achievable 159 using PKI mechanisms, it will likely remain desirable to continue to 160 provide support for existing and new User-Level Authentication (ULA) 161 techniques which may be used in conjunction with PKI mechanisms. In 162 general, existing ULA techniques are based on one of 2 mechanisms: 163 static pass phrases, or dynamic tokens. Dynamic tokens may be time- 164 dependent, or may be formulated as a response to a challenge of some 165 sort, while static pass phrases are generally text strings of some 166 sort which are associated with a given identity. Static pass phrases 167 are usually a very weak form of authentication. On the other hand, 168 they will likely remain popular due to their convenience. 170 It seems clear that the ideal solution to the ULA problem entails an 171 approach which supports existing ULA mechanisms while paving the way 172 for PKI deployment, since such mechanisms will likely continue to be 173 required even after a PKI is deployed. Therefore, our goal should be 174 to provide an integration strategy which couples these mechanisms in 175 the most secure manner. Such a strategy necessarily entails a PKI 176 transition. This is discussed in the next session. 178 2.2 The PKI Transition 180 The need for integration of a PKI transition strategy with the 181 deployment of other ULA mechanisms is evidenced by the movement 182 toward providing ULA mechanisms within IKE as a response to remote 183 access requirements. In general, some sort of PKI is a hard 184 requirement for widespread deployment of secure remote access 185 solutions, since the security of preshared keys is highly dubious in 186 this context. The issues associated with such a PKI transition are 187 discussed below. 189 The transition to a PKI may be divided into several steps: 191 a. Support for PKI on VPN servers. This typically requires that 192 machine certificates be deployed on the servers, along with 193 appropriate certificate authorities and stores. It also requires 194 that clients be capable of verifying the server's certificate 195 against a current Certificate Revocation List (CRL). Since this 196 will often require a client software upgrade, the work to 197 transition to server certificates is comparable to the work 198 required to deploy SSL/TLS-capable Web server and certificate- 199 capable browsers. 201 Note that while client software support for PKI must be assumed, 202 in this step, it is not necessary for the clients to obtain their 203 own machine or user certificates. Thus it is possible for the 204 clients to continue to authenticate using only legacy methods 205 during this phase of the transition. 207 b. Support for machine certificates on VPN clients. This requires 208 that machine certificates be deployed on VPN clients. Completion 209 of the previous step (a) often requires a client upgrade, which 210 will typically also include support for client certificates. If 211 the infrastructure for machine auto-enrollment has also been put 212 in place as part of the server PKI rollout, then there may not be 213 much additional work required to complete this step, above what 214 was already required for the previous step. Note that if the VPN 215 client only supports a machine certificate, then this may imply 216 the use of a non-PKI method for user authentication in addition to 217 the machine certificate. 219 c. Support for user certificates. This requires that user 220 certificates be provided to users. Since storage of user 221 certificates on the machine creates new vulnerabilities, 222 smartcards may typically be used to store the user certificates. 223 Thus, a smartcard rollout may often be a prerequisite to 224 deployment of user certificates. This in turn may require 225 integration of smartcard provisioning with the existing 226 identification system, such as the distribution of combined 227 employee badge/smartcards. Since this step may require 228 considerable work above and beyond the tasks required to carry out 229 transition steps a and b, support for legacy authentication 230 methods will likely be required at least until this transition 231 step is complete. 233 2.3 Previously Proposed Solutions 235 There have been at least two mechanisms proposed as solutions for the 236 ULA problem thus far, and these are discussed in [XAUTH] and 237 [HYBRID]. While these documents do not explicitly acknowledge the 238 need for a PKI transition, they rely heavily upon it. [XAUTH] relies 239 upon it because it requires a reliable authentication mechanism for 240 the communicating systems (i.e. PK certificates) in order to be 241 meaningful in a security context, and [HYBRID] relies upon it due 242 both to its incorporation of PK certificates on the server side (and 243 verification on the client side), and to its reliance on [XAUTH] as 244 an underlying framework. These are discussed individually below, 245 followed by a discussion of an alternative mechanism. 247 2.4 Extended Authentication within IKE (xauth) 249 The xauth mechanism [XAUTH] utilizes an existing phase 1 IKE Security 250 Association (SA) to protect a secondary authentication exchange 251 within IKE prior to negotiation of an IPsec protocol SA. This is 252 often referred to as "phase 1.5" due to its juxtaposition between IKE 253 phases 1 and 2. This mechanism currently relies upon another proposed 254 IKE protocol extension mechanism [ISACFG], and both substantially 255 modify the existing IKE protocol. The following diagram clarifies the 256 relationships of the various components: 258 +------------------+ 259 +---------+ | security gateway | +--------+ 260 | radius |------| +---------------+| IKE SA | remote | 261 | server | | | co-resident ||<=========>| client | 262 | |<======>|authentication || | | 263 +---------+ | | proxy appl. || +--------+ 264 | +---------------+| 265 +------------------+ 267 Issues with xauth include the following: 269 o susceptible to man-in-the-middle attack if preshared 270 key is used for IKE authentication, and so requires 271 both server and client PK certificates for most 272 deployments. 274 o depends upon yet another framework for its basis [ISACFG] 276 o adds significant complexity to the key exchange protocol, 277 not only by adding an open-ended number of challenge- 278 response exhanges, but by providing proxy support for 16 279 different legacy authentication mechanisms. The resultant 280 implementation complexity introduces significant 281 security risks. 283 o there is substantial known plaintext in the encrypted 284 exchanges. 286 These are serious issues, and should disqualify this proposal from 287 serious consideration as a security protocol extension. To clarify, 288 each of these issues is discussed individually below. 290 Man-in-the-middle attacks 292 The vulnerability to man-in-the-middle attacks occurs because in 293 preshared key authentication in main mode, it is necessary for keys 294 to be computed prior to the receipt of the identification payload. 295 Therefore the selection of the preshared key may only be based on 296 information contained in the IP header. However, in remote access 297 situations, dynamic IP address assignment is the rule, so that it 298 is typically not possible to map an IP address to a user identity 299 and a preshared key. Thus the preshared key can no longer function 300 as an effective shared secret; the same preshared key must be 301 shared by a group of users. In this situation, neither the client 302 nor the server individually authenticates itself during IKE phase 303 1; it is only known that both parties are a member of a group with 304 access to the shared secret. This permits anyone with access to the 305 group secret to act as a man-in-the-middle. Hence, [XAUTH] requires 306 both server and client certificates in most cases. 308 Note that this vulnerability does not occur in aggressive mode 309 since the identity payload is sent earlier in the exchange. Of 310 course, when aggressive mode is used the user identity is exposed 311 and this may be undesirable. In fact, aggressive mode raises other 312 security concerns, but these are not discussed here. 314 Dependency on [ISACFG] 316 [XAUTH] requires support for the additional proposed configuration 317 mechanism described in [ISACFG]. This presupposes that this 318 configuration framework is appropriate in its own right, but this 319 has not been demonstrated. Binding [XAUTH] to [ISACFG] increases 320 the difficulty associated with complexity analysis, and requires 321 that the two proposals advance together. 323 Complexity Issues 325 The approach described in [XAUTH] significantly complicates IKE by 326 adding a new exchange type, by extending the negotiation process in 327 an open-ended fashion, by binding itself to yet another IKE 328 extension, and by adding text-string processing requirements. 329 While either of the first two issues taken alone might not be cause 330 for much alarm, the aggregation of these, along with the others, 331 render this mechanism significantly more complex than the base IKE 332 exchange, and much more prone to error. Given the critical nature 333 of the key exchange with respect to the resulting session security, 334 it is imprudent to unnecessarily introduce complexity to this 335 protocol component. 337 Known Plaintext 339 There is a significant amount of known plaintext in the exchanges 340 described in [XAUTH]. Below is an example exchange. Note that the 341 text given here in upper case is precisely what is encrypted and 342 sent over the wire (for the given authentication type), as 343 documented in [XAUTH]: 345 IPSec Host Edge Device 346 -------------- ----------------- 347 <-- REQUEST(TYPE=GENERIC NAME="" 348 PASSWORD="") 350 REPLY(TYPE=GENERIC NAME="joe" 351 PASSWORD="foobar") --> 353 <-- REQUEST(TYPE=GENERIC 354 MESSAGE="Enter your password 355 followed by your pin number" 356 NAME="" PASSWORD="") 358 REPLY(TYPE=GENERIC NAME="joe" 359 PASSWORD="foobar0985124") --> 361 <-- SET(STATUS=OK) 363 Without question, there is a significant amount of known plaintext 364 here. An adversary could passively collect any number of these 365 exchanges, and then analyze them at leisure. Note that it is not 366 necessary to break the session in real time in order to compromise 367 a password and subsequently gain access to the remote network. 368 However, real time attacks are a possibility in sufficiently long- 369 lived sessions. 371 It must be emphasized that it is not the general functionality that 372 [XAUTH] strives for which is in question here, though the 373 advisability of providing proxy protocol support for 16 different 374 legacy authentication mechanisms is certainly questionable. Rather, 375 it is the insertion of this mechanism into the key exchange protocol, 376 and the general manner in which it is constructed, which should be 377 recognized as imprudent. 379 Note that the support for such a large number of legacy methods 380 appears unnecessary, given that most of the mechanisms are already 381 supported within existing IETF standards-track frameworks such as 382 GSS_API [GSS], SASL [SASL] and EAP [RFC2284]. Thus, the introduction 383 of yet another user authentication framework is highly inefficient. 384 By leveraging existing frameworks it would be possible to 385 simultaneously provide wider legacy support while dramatically 386 decreasing the code and complexity required to provide this 387 functionality. 389 2.5 A Hybrid Authentication Mode for IKE 391 The hybrid authentication method [HYBRID] uses [XAUTH] as a framework 392 upon which to build. Hence, it suffers from many of the deficiencies 393 of [XAUTH], namely excessive key exchange protocol complexity, 394 dependency on [ISACFG], and substantial known plaintext in the 395 exchanges. However, the hybrid mechanism resolves the man-in-the- 396 middle susceptibility by requiring the security gateway to 397 authenticate using a certificate, while permitting the user to be 398 authenticated based upon some challenge-response mechanism. 400 By only requiring a server certificate, Hybrid authentication 401 provides more transition benefits than [XAUTH], which can only be 402 safely deployed with both server and client machine certificates. 403 However, as noted earlier, once full server certificate support is 404 put in place, there may not be that much extra work involved in 405 supporting client machine certificates. Thus the hybrid approach may 406 provide only limited transition benefits above what is already 407 supported in IKE. 409 If [HYBRID] were made independent of [XAUTH], it would be 410 substantially enhanced. However, there would still be questions as to 411 its necessity and utility. For [HYBRID] to provide meaningful 412 security, the client must be able to validate the security gateway's 413 certificate, or else session is susceptible to a man-in-the-middle 414 attack. That is, this functionality relies upon the presence of a PKI 415 infrastructure for its security. So, [HYBRID] requires a meaningful 416 PKI capability in both the client and the server, yet it stops short 417 of simply taking one more step and enrolling the client for a 418 certificate of its own. If the client had its own certificate, the 419 need for the hybrid framework would disappear entirely. 421 On the other hand, and especially in view of the desire for legacy- 422 to-PKI transition mechanisms, there may yet be some limited 423 usefulness for the hybrid approach, especially if it is freed from 424 dependence upon xauth. The authors of [HYBRID] are invited to 425 consider how its general principles might be integrated into the 426 framework presented below. 428 2.6 Reasonable design goals 430 Before proceeding to propose a solution to the various problems 431 associated with ULA in the IPsec context, we should first assert some 432 design goals. These might include the following: 434 o Provide support for existing legacy components, and make 435 it transparent inasmuch as this is possible 437 o Permit a transition to Public Key infrastructure beginning 438 at step a in the transition process, support for server 439 certificates. 441 o Use the existing IPsec framework without modification if 442 possible 444 o Use existing standardized authentication framework(s) 446 o Provide mechanisms which ultimately encourage migration 447 toward newer, stronger authentication technologies, but 448 which do not force such migration. Regardless, do not 449 permit a failure to migrate to more appropriate techno- 450 logies by some administrators to precipitate the weaken- 451 ing of security protocols as an IETF response. 453 3. An Alternative to Xauth and Hybrid 455 3.1 Overview 457 It is not difficult to arrive at an alternative to xauth/hybrid which 458 does not suffer from many of the associated shortcomings, given the 459 design goals enumerated above. Supporting existing legacy systems 460 requires either that the client or the security gateway (sgw) speak 461 with the legacy authentication server. If this is to be password 462 based, it makes sense that the sgw implements a proxy server so that 463 it is privy to the results of the exchange, and this is also 464 supported by the desire to use an existing standardized 465 authentication protocol. Also, if we are to use the existing Ipsec 466 framework, we must somehow use the policy database on the sgw to 467 control access. And if we are to encourage migration, we should 468 strive to encourage the use of a PKI in place of or in addition to 469 transmitted passwords or tokens. Given these considerations, a fairly 470 straightforward scheme emerges, detailed below: 472 o the security gateway implements a co-resident 473 authentication proxy application which uses a 474 standard authentication protocol. 476 o the client establishes a securely authenticated IKE 477 SA followed by an IPsec SA with selectors which indicate 478 the authentication proxy application on the gateway. 480 o the client interacts with the authentication proxy, 481 providing a password, token or whatever is required. 483 o if the client successfully authenticates, the 484 authentication proxy adds selectors to the Security 485 Policy Database (SPD) which permit access to the 486 corporate network. These selectors MAY point to the 487 same phase 2 SA as was used for authentication, or 488 MAY require the instantiation of new phase 2 SA. In 489 the case of a new phase 2 SA, the original selectors 490 permitting access to the proxy application MAY remain as 491 well, allowing for later re-authentication if needed. 492 This selector addition results in a temporary selector 493 entry in the same manner as name selectors described 494 in [RFC2401, p19]. 496 o If the client fails to authenticate after a (small) 497 predetermined number of attempts, the client MUST be 498 locked out. Failure to authenticate is an auditable 499 event. 501 This mechanism is much simpler than those previously proposed, in 502 that it relies almost entirely upon the existing framework, and 503 requires no modifications to existing IPsec protocols. Compliant 504 IPsec implementations should already support the addition of 505 temporary policy selectors, and existing xauth/hybrid implementations 506 already must support a co-resident authentication proxy. 508 3.2 The ULA Protocol 510 Of fundamental importance to the simplicity of the above described 511 mechanism is the authentication proxy, and the protocol(s) it 512 supports. Other proposed mechanisms advocate support for numerous 513 individual mechanisms, leading to unacceptable implementation 514 complexity. This problem has been addressed within existing IETF 515 authentication frameworks such as EAP [RFC2284], GSS_API [GSS], and 516 SASL [SASL]. 518 Note that while these frameworks provide differing degrees of 519 integrity protection taken on their own, when carried out under the 520 protection of an IPSEC SA based on a fully authenticated IKE SA, they 521 would inherit the authentication, integrity and replay protection 522 services of IPSEC. This would be effectively realized by 523 encapsulation of relevant authentication protocol exchanges within an 524 IP transport protocol. Note that while GSS_API and EAP can be 525 encapsulated within UDP, SASL support assumes TCP transport. Thus an 526 additional port would be needed to serve as a UDP/TCP endpoint. 528 4. Shortcomings and Strengths compared to other mechanisms 530 4.1 Shortcomings 532 o this approach is somewhat susceptible to Denial of 533 Service (DoS) attacks, due to the amount of processing 534 necessary to generate both IKE and IPsec protocol Sas. 535 However, such an attack requires that the phase 1 536 credential be compromised, and may be mitigated by 537 lockout after some number of failures. 539 o There may be known plaintext in the authentication 540 exchange. This may be mitigated by random ordering of 541 TLV payloads within the exchange, and in any event, 542 this mechanism provides far less known plaintext than 543 xauth or hybrid. 545 4.2 Strengths 547 o no modifications to existing IPsec protocols 549 o significantly reduces implementation complexity 551 o provides clear migration path to PKI-based mechanisms 553 o utilizes standardized authentication protocols 555 5. Security Considerations 557 This document describes a mechanism for providing various degrees of 558 user-level authentication prior to allowing general access via an 559 IPsec protocol SA. It is assumed that the IKE (phase 1) SA is 560 authenticated in a meaningful manner prior to engaging in user-level 561 authentication. If preshared keys are used for such authentication, 562 extreme care must be exercised in distributing and storing these 563 keys, since compromise of the preshared key results in susceptibility 564 to a man-in-the-middle attack. In cases where compromise could result 565 in significant loss, preshared keys SHOULD NOT be used. 567 It must be emphasized that this mechanism adds nothing to the 568 security of the underlying IKE/IPsec SAs, but simply serves instead 569 to authenticate a user whose data is to be transported within the 570 associated protocol SA. 572 6. Authors' Addresses 574 Scott Kelly 575 RedCreek Communications 576 3900 Newpark Mall Road 577 Newark, CA 94560 578 USA 579 email: skelly@redcreek.com 580 Telephone: +1 (510) 745-3969 582 Jim Knowles 583 RedCreek Communications 584 3900 Newpark Mall Road 585 Newark, CA 94560 586 USA 587 email: jknowles@redcreek.com 588 Telephone: +1 (510) 745-3977 590 Bernard Aboba 591 Microsoft Corporation 592 One Microsoft Way 593 Redmond, WA 98052 594 USA 595 email: bernarda@microsoft.com 596 Telephone: +1 (425) 936-6605 598 Full Copyright Statement 600 Copyright (C) The Internet Society (1998). All Rights Reserved. 602 This document and translations of it may be copied and furnished 603 to others, and derivative works that comment on or otherwise 604 explain it or assist in its implementation may be prepared, 605 copied, published and distributed, in whole or in part, without 606 restriction of any kind, provided that the above copyright notice 607 and this paragraph are included on all such copies and derivative 608 works. However, this document itself may not be modified in any 609 way, such as by removing the copyright notice or references to 610 the Internet Society or other Internet organizations, except as 611 needed for the purpose of developing Internet standards in which 612 case the procedures for copyrights defined in the Internet 613 Standards process must be followed, or as required to translate 614 it into languages other than English. 616 The limited permissions granted above are perpetual and will not 617 be revoked by the Internet Society or its successors or assigns. 619 This document and the information contained herein is provided on 620 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 621 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 622 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 623 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 624 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 625 PURPOSE. 627 7. References 629 [GSS] Linn, J., "Generic Security Service Application 630 Program Interface, Version 2", RFC 2078, January 631 1997. 633 [HYBRID] M. Litvin, R. Shamir, and T. Zegman, "A Hybrid 634 Authentication Mode for IKE", June 1999, 635 draft-ietf-ipsec-isakmp-hybrid-auth-02.txt 637 [ISACFG] R. Pereira, "The ISAKMP Configuration Method", 638 draft-ietf-ipsec-isakmp-cfg-03, (expired) 640 [RADIUSEXT] Rigney, C., Willens, S., Calhoun, P., "RADIUS 641 Extensions", draft-ietf-radius-ext-04.txt, 642 Internet Draft (work in progress), May 1999. 644 [SASL] Myers, J., "Simple Authentication and Security 645 Layer (SASL)", RFC 2222, October 1997. 647 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol 648 (PPP)." STD 51, RFC 1661, July 1994. 650 [RFC2138] C. Rigney, A. Rubens, W. Simpson, S. Willens, 651 "Remote Authentication Dial In User Service 652 (RADIUS)", RFC2138 654 [RFC2284] L. Blunk, J. Vollbrecht, "PPP Extensible 655 Authentication Protocol (EAP)", RFC 2284, 656 March 1998. 658 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture 659 for the Internet Protocol", RFC 2401, 660 November 1998. 662 [RFC2409] Harkins, D., and D. Carrel, "The Internet Key 663 Exchange (IKE)", RFC 2409, November 1998. 665 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., 666 Zorn, G., and Palter, B., "Layer Two Tunneling 667 Protocol L2TP", RFC 2661, August 1999. 669 [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication 670 Within ISAKMP/Oakley", September 1999, 671 draft-ietf-ipsec-isakmp-xauth-05.txt