idnits 2.17.00 (12 Aug 2021) /tmp/idnits41910/draft-aboba-ipsra-req-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 87: '...in [19] and [26]. As a result, while an IPSEC remote access protocol MAY...' RFC 2119 keyword, line 118: '...EC remote access MUST provide for both...' RFC 2119 keyword, line 130: '...IPSEC remote access SHOULD support the...' RFC 2119 keyword, line 131: '...ation lease, and MAY support the abili...' RFC 2119 keyword, line 138: '...r IPSEC remote access MUST support the...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 302 has weird spacing: '... the infras...' == Line 612 has weird spacing: '...t>, and expir...' -- 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.) -- The document date (21 November 2000) is 7844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 422 looks like a reference -- Missing reference section? '19' on line 480 looks like a reference -- Missing reference section? '26' on line 505 looks like a reference -- Missing reference section? '3' on line 428 looks like a reference -- Missing reference section? '4' on line 431 looks like a reference -- Missing reference section? '7' on line 441 looks like a reference -- Missing reference section? '14' on line 464 looks like a reference -- Missing reference section? '6' on line 437 looks like a reference -- Missing reference section? '21' on line 488 looks like a reference -- Missing reference section? '8' on line 444 looks like a reference -- Missing reference section? '12' on line 457 looks like a reference -- Missing reference section? '23' on line 496 looks like a reference -- Missing reference section? '22' on line 493 looks like a reference -- Missing reference section? '24' on line 499 looks like a reference -- Missing reference section? '20' on line 484 looks like a reference -- Missing reference section? '40' on line 549 looks like a reference -- Missing reference section? '15' on line 468 looks like a reference -- Missing reference section? '31' on line 521 looks like a reference -- Missing reference section? '30' on line 518 looks like a reference -- Missing reference section? '29' on line 515 looks like a reference -- Missing reference section? '38' on line 542 looks like a reference -- Missing reference section? '41' on line 552 looks like a reference -- Missing reference section? '2' on line 425 looks like a reference -- Missing reference section? '5' on line 434 looks like a reference -- Missing reference section? '9' on line 448 looks like a reference -- Missing reference section? '10' on line 451 looks like a reference -- Missing reference section? '11' on line 454 looks like a reference -- Missing reference section? '13' on line 460 looks like a reference -- Missing reference section? '16' on line 472 looks like a reference -- Missing reference section? '17' on line 475 looks like a reference -- Missing reference section? '18' on line 478 looks like a reference -- Missing reference section? '25' on line 502 looks like a reference -- Missing reference section? '27' on line 509 looks like a reference -- Missing reference section? '28' on line 511 looks like a reference -- Missing reference section? '33' on line 524 looks like a reference -- Missing reference section? '34' on line 527 looks like a reference -- Missing reference section? '35' on line 531 looks like a reference -- Missing reference section? '36' on line 536 looks like a reference -- Missing reference section? '37' on line 539 looks like a reference -- Missing reference section? '39' on line 545 looks like a reference -- Missing reference section? '42' on line 557 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 43 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Informational 5 6 21 November 2000 8 IPSEC Remote Access Protocol Evaluation Criteria 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 The distribution of this memo is unlimited. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 3. Abstract 37 This document describes criteria for evaluation of IPSEC Remote Access 38 (IPSRA) protocols. In particular, this document focuses on criteria 39 relevant to voluntary tunneling. 41 4. Introduction 43 This document describes criteria for evaluation of IPSEC Remote Access 44 (IPSRA) protocols. In particular, this document focuses on criteria 45 relevant to voluntary tunneling. 47 5. Requirements language 49 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 50 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 51 described in [1]. 53 Please note that the criteria specified in this document are to be used 54 in evaluating protocol submissions. As such, the requirements language 55 refers to capabilities of these protocols; the protocol documents will 56 specify whether these features are required, recommended, or optional. 57 For example, requiring that a protocol support confidentiality is NOT 58 the same thing as requiring that all protocol traffic be encrypted. 60 A protocol submission is not compliant if it fails to satisfy one or 61 more of the must or must not requirements for the capabilities that it 62 implements. A protocol submission that satisfies all the must, must 63 not, should and should not requirements for its capabilities is said to 64 be "unconditionally compliant"; one that satisfies all the must and must 65 not requirements but not all the should or should not requirements for 66 its protocols is said to be "conditionally compliant." 68 6. Overview 70 Requirements may be divided into several categories: 72 Multi-protocol requirements 73 Configuration requirements 74 Overhead requirements 75 PKI transition requirements 76 Authentication requirements 77 Accounting and auditing requirements 78 Security requirements 80 6.1. Multiprotocol requirements 82 With the widespread acceptance of IP, the usage of alternative protocols 83 such as IPX, SNA, NetBEUI, and AppleTalk is declining rapidly. Thus 84 while multi-protocol networks are still common today, this is not 85 expected to be the case within five years. For those networks requiring 86 multi-protocol support, alternatives are widely available, as described 87 in [19] and [26]. As a result, while an IPSEC remote access protocol MAY 88 provide multi-protocol support, this is at best a minor objective, and 89 protocol designers would be wise to optimize for IP. 91 Note that in order to provide for multi-protocol support, it is not 92 necessary to encapsulate GRE or PPP within IPSEC. Rather, IPSEC can 93 readily support multi-protocol tunneling via inclusion of the non-IP 94 protocol number in the "Next Header" field of the AH or ESP header. 96 Since multi-protocol use is declining rapidly, support for multi- 97 protocol configuration such as what was provided in PPP, described in 98 [16]-[18], is not a requirement for an IPSEC remote access protocol. 99 Thus, it is feasible for an IPSEC remote access solution to focus solely 100 on IP configuration mechanisms. 102 6.2. Configuration requirements 104 The configuration requirements of a host with an IPSEC remote access 105 interface are similar to those of a host needing to configure any other 106 kind of interface. These include the need: 108 1. to obtain an IP address and other configuration parameters 109 appropriate to the class of host 110 2. to reconfigure when required 111 3. to authenticate where required 112 4. to support address pool management 113 5. to support fail-over 114 6. to integrate with existing IP address management 115 facilities such as DHCP 116 7. to maintain security and simplicity in the IKE implementation. 118 A configuration facility for IPSEC remote access MUST provide for both 119 IP address assignment as well as configuration for a wide variety of 120 parameters, such as those supported in DHCP [3]. Note that rich 121 configuration facilities have already proved necessary in wide variety 122 of cases outside of conventional LAN configuration. For example, in the 123 case of PPP, IPCP, described in [4], was used to provide for IP address 124 assignment. However, it was found that additional configuration 125 parameters were necessary, so that non-standard extensions, described in 126 [7] were developed. Rather than continuing down the road towards 127 duplicating existing DHCP functionality, it was decided that it would be 128 preferable to support DHCPINFORM capabilities, described in [3]. 130 A configuration facility for IPSEC remote access SHOULD support the 131 concept of a configuration lease, and MAY support the ability to force 132 reconfiguration of the client, in a manner such as that described in 133 [14]. Configuration leases permit recovery of unused IP address space, 134 and therefore result in more optimal use of addresses. The ability to 135 force reconfiguration of the client can be useful in a number of 136 circumstances, such as renumbering. 138 A configuration facility for IPSEC remote access MUST support the 139 ability to authenticate the configuration conversation. As noted in 140 [6], a number of security threats exist in IP address management, and so 141 authentication may be desirable in order to mitigate these threats. 142 Alternatively, it may be desirable to bind an IP address to a user or 143 machine ID for the purposes of supporting policy-based networking. Note 144 that the need for authentication is particularly strong where forced 145 reconfiguration is supported. Where DHCP authentication is implemented 146 for these purposes, IPSEC remote access addressing SHOULD permit 147 integration with DHCP authentication so as to permit universal coverage. 149 A configuration facility for IPSEC remote access SHOULD provide the 150 ability to be able to obtain an IP address within the appropriate 151 address pool. Today it is common to use distinct address pools for the 152 purposes of service differentiation, and therefore the ability to obtain 153 an address from the appropriate pool may be critical to the operation of 154 the network. Methods for pool assignment include the user identity 155 option as well as the user class option specified in [21]. 157 A configuration facility for IPSEC remote access SHOULD NOT preclude the 158 ability to provide for fail-over capabilities in terms of IP address 159 management. With enterprise customers increasingly investing in IP 160 address management systems with fail-over capabilities, creating 161 additional pockets of addressing state creates the the need to provide 162 those additional pockets with fail-over capabilities equivalent to those 163 provided in DHCP fail-over, described in [8]. 165 A configuration facility for IPSEC remote access MUST NOT compromise the 166 simplicity or security of IKE, described in [12]. Since IKE is a key 167 element of the Internet security architecture, it is critical to 168 maintain inter-operability as well as the ability to predict and analyze 169 the behavior of implementations. 171 6.3. Overhead requirements 173 Given the increasing popularity of IPSEC remote access, it is inevitable 174 that this technology will be used in a wide variety of applications, 175 including transport of voice and video. These applications typically 176 involve transport of small payloads, and as a result the level of 177 overhead introduced by an IPSEC remote access protocol is of concern. 179 It is possible that existing header compression schemes may be operating 180 within an IPSEC remote access environment. These schemes are used to 181 reduce the size of IP headers encapsulated within the IPSEC remote 182 access headers. For example, the IP header compression scheme described 183 in [23], or IPSEC minimal encapsulation, described in [22] may be in 184 use. Where voice or video payloads are being carried within RTP, the 185 IP/UDP/RTP compression scheme described in [24] may prove useful. 187 For the purpose of the comparisons that follow, the packet to be 188 encapsulated by the IPSEC remote access protocol may be assumed to have 189 been previously compressed by one of the above methods. For comparison 190 purposes, overhead is calculated for a 700 octet packet as well as a 64 191 octet packet, In this calculation we assume an IP header of 20 octets, 192 a UDP header of 8 octets, an IPSEC header of 32 octets (corresponding to 193 MD5 IPSEC AH) and (where applicable) an L2TP header of 8 octets. 194 Overhead percentage is calculated as overhead/packet size. 196 As described below, for the case of the 64 octet packet, all known 197 methods result in excessive overhead. Thus an IPSEC remote access 198 protocol MAY provide additional mechanisms to reduce overhead in these 199 scenarios. 201 6.3.1. IPSEC tunnel mode 203 In IPSEC tunnel mode, an IP header is used inside the IP and IPSEC 204 headers. Thus, an IP packet would require an additional 52 octets of 205 overhead for the addition of IP and IPSEC headers. 207 For a 64 octet packet, this results in overhead of 81.8%. For a 700 208 octet packet, overhead is 7.4%. 210 6.3.2. IPSEC/L2TP 212 L2TP, defined in [19], involves encapsulation of PPP within UDP and 213 L2TP. Where IPSEC is used to provide security, 68 octets of overhead are 214 required. 216 For a 64 octet packet, this results in overhead of 106.3%. For a 700 217 octet packet, overhead is 9.7%. 219 6.3.3. IPSEC/L2TP with header compression 221 L2TP header compression, defined in [20], involves encapsulation of an 222 L2TPHC header, which can be as small as a single octet, within IP. Thus 223 where IPSEC is used to provide security, 53 octets of overhead are 224 required. 226 For a 64 octet packet, this results in overhead of 82.8%. For a 700 227 octet packet, overhead is 7.6%. 229 6.3.4. IPSEC/L2TP with multiple PPP encapsulation 231 Using L2TP it is possible to include more than one PPP encapsulated 232 frame within a single L2TP packet. This results in a reduction in 233 overhead and attendant serialization time, at the expense of additional 234 delay required to accumulate additional packets. Where the serialization 235 time saved is greater than the additional delay, the tradeoff will be 236 worthwhile. This is typically the case at bandwidths of less than 100 237 Kbps. 239 For the purposes of calculating overhead, let us assume that two 64 240 octet packets are bundled together. This results in overhead of 53.2%. 241 For a 700 octet packet, overhead is 4.9%. 243 6.4. Summary 245 A summary of the overhead computed for each method is given below: 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | Overhead | Overhead | 249 | Protocol | w/ 64 octet | w/ 700 octet | 250 | | packet | packet | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | | | 253 | IPSEC/L2TP | 106.3% | 9.7% | 254 | | | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | | | 257 | IPSEC/L2TP w/HC | 82.8% | 7.6% | 258 | | | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | | | 261 | IPSEC tunnel mode | 81.8% | 7.4% | 262 | | | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | | | 265 | IPSEC/L2TP w/ | 53.2% | 4.9% | 266 | multiple PPP enc. | | | 267 | | | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 6.5. PKI transition requirements 272 An IPSEC remote access protocol MUST provide customers with the ability 273 to deploy the solution securely without requiring that clients implement 274 user certificates. An IPSEC remote access solution MUST support user 275 authentication in the case where client and server machine certificates 276 are present and SHOULD support user authentication in the case where 277 only the server has a machine certificate, but the client does not have 278 any certificate. 280 The transition to a PKI may be divided into several steps: 282 a. Support for PKI on servers. This typically requires that 283 machine certificates be deployed on the servers, along with 284 appropriate certificate authorities and stores. It also requires 285 that clients be capable of verifying the server's certificate 286 against a current Certificate Revocation List (CRL). Since this 287 will often require a client software upgrade, the work to 288 transition to server certificates is comparable to the work 289 required to deploy SSL/TLS-capable Web server and certificate- 290 capable browsers. 292 Note that while some client software support for PKI must be 293 assumed, in this step, it is not necessary for the clients to 294 obtain their own machine or user certificates. Thus it is possible 295 for the clients to continue to authenticate using only legacy 296 methods during this phase of the transition. 298 b. Support for machine certificates on clients. This requires 299 that machine certificates be deployed on clients. Completion 300 of the previous step (a) often requires a client upgrade, which 301 will typically also include support for client certificates. If 302 the infrastructure for machine auto-enrollment has also been put 303 in place as part of the server PKI rollout, then there may not be 304 much additional work required to complete this step, above what 305 was already required for the previous step. Note that if the 306 client only supports a machine certificate, then this may imply 307 the use of a non-PKI method for user authentication in addition to 308 the machine certificate. 310 c. Support for user certificates. This requires that user 311 certificates be provided to users. Since storage of user 312 certificates on the machine creates new vulnerabilities, 313 smart-cards are typically be used to store the user certificates. 314 Thus, a smart-card rollout may often be a prerequisite to 315 deployment of user certificates. This in turn may require 316 integration of smart-card provisioning with the existing 317 identification system, such as the distribution of combined 318 employee badge/smart-cards. Since this step may require 319 considerable work above and beyond the tasks required to carry out 320 transition steps a and b, support for legacy authentication 321 methods will likely be required at least until this transition 322 step is complete. 324 Thus, an IPSEC remote access solution MUST support transition step b, 325 and SHOULD support transition step a. 327 6.6. Authentication requirements 329 An IPSEC remote access protocol MUST support user authentication and 330 MUST offer compatibility with legacy authentication methods commonly in 331 use today. This includes PPP authentication methods, described in [40]. 332 Note that since RADIUS, defined in [15], merely serves to encapsulate an 333 authentication method, it does not itself constitute an authentication 334 method. 336 Since support for a variety of authentication methods is already 337 available within existing IETF standard frameworks such as such as 338 GSS_API [31], an IPSEC remote access protocol SHOULD support the GSS_API 339 authentication framework and MAY support other frameworks such as SASL 340 [30] or EAP [29]. 342 Support for existing frameworks is important since creating new 343 frameworks increases the complexity of developing new authentication 344 methods and while also complicating their deployment. Rather than 345 fragmenting the market while increasing the cost of development, a more 346 useful approach is to unify the authentication frameworks, making it 347 possible for developers to create authentication modules that will be 348 usable in a variety of applications. 350 Work toward support of GSS_API within other frameworks is already 351 underway. For example, SASL, described in [30], already supports 352 negotiation of GSS_API as a method, as noted in [38]. Similarly, work on 353 permitting GSS_API to be used for initial authentication [41], has 354 enabled GSS_API support within EAP. 356 6.7. Accounting and auditing requirements 358 An IPSEC remote access protocol SHOULD support accounting and auditing. 359 In order to support accounting, it is necessary to be able to accurately 360 determine the duration of the IPSEC remote access session. Without a 361 standardized IPSEC keep-alive this can prove difficult to achieve since 362 security associations may remain in place after a client disconnect or 363 crash. 365 6.8. Security requirements 367 6.8.1. Identity protection 369 An IPSEC remote access protocol MUST provide for identity protection. 370 Since IKE Aggressive Mode exposes the user identity, an IPSEC remote 371 access protocol MUST NOT rely on aggressive mode. For example, an IPSEC 372 remote access solution MUST protect against man in the middle attacks 373 without requiring the use of Aggressive Mode. 375 Note that main mode with signature authentication is secure against 376 passive attacks but not active attacks. 378 6.8.2. Denial of service attacks 380 Denial of service attacks can be characterized based on the capabilities 381 of the attacker: 383 1. Attackers that can send and receive IP-address spoofed 384 messages corresponding to one real party in the attack. 385 2. Attackers that can only send IP-address spoofed messages 386 corresponding to one real party in the attack (but not receive). 388 3. Attackers that can gain physical access to the device 389 being attacked. 391 An IPSEC remote access protocol MUST provide protection against attacks 392 in categories 1 and 2. Attackers in category 3 are able to deny service 393 without having to attack on the wire protocols, so that there is little 394 that can be done to deter them within an IPSEC remote access protocol. 396 6.8.3. Man-in-the-middle attacks 398 Use of pre-shared keys in main mode is vulnerable to man-in-the-middle 399 attacks when used for IPSEC remote access. This occurs since in main 400 mode it is necessary for SKEYID_e to be used prior to the receipt of the 401 identification payload. Therefore the selection of the pre-shared key 402 may only be based on information contained in the IP header. However, in 403 remote access situations, dynamic IP address assignment is the rule, so 404 that it is typically not possible to identify the required pre-shared 405 key based on the IP address. 407 Thus when pre-shared keys are used in IPSEC remote access, the same pre- 408 shared key is shared by a group of users and is no longer able to 409 function as an effective shared secret. In this situation, neither the 410 client nor the server identifies itself during IKE phase 1; it is only 411 known that both parties are a member of the group with knowledge of the 412 pre-shared key. This permits anyone with access to the group pre-shared 413 key to act as a man-in-the-middle. 415 Note that this vulnerability does not occur in aggressive mode since the 416 identity payload is sent earlier in the exchange. However, when 417 aggressive mode is used the user identity is exposed and this may be 418 undesirable. 420 7. References 422 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 423 Levels", BCP 14, RFC 2119, March 1997. 425 [2] Atkinson, R., Kent, S., "Security Architecture for the Internet 426 Protocol", RFC 2401, November 1998. 428 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 429 1997. 431 [4] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", 432 RFC 1332, May 1992. 434 [5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 435 Extensions", RFC 2132, March 1997. 437 [6] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 438 Internet draft (work in progress), draft-ietf-dhc- 439 authentication-11.txt, June 1999. 441 [7] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for 442 Name Server Addresses", RFC 1877, December 1995. 444 [8] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., 445 Dooley, M., Kapur, A., "DHCP Failover Protocol", Internet draft 446 (work in progress), draft-ietf-dhc-failover-04.txt, June 1999. 448 [9] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 449 November 1998. 451 [10] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 452 RFC 2406, November 1998. 454 [11] Piper, D., "The Internet IP Security Domain of Interpretation of 455 ISAKMP", RFC 2407, November 1998. 457 [12] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 458 2409, November 1998. 460 [13] Pereira, R., Anand, S., Patel, B., "The ISAKMP Configuration 461 Method", Internet draft (work in progress), draft-ietf-ipsec- 462 isakmp-mode-cfg-05.txt, August 1999. 464 [14] De Schrijver, P., T'Joens, Y., "Dynamic host configuration : DHCP 465 reconfigure extension", Internet draft (work in progress), draft- 466 schrijvp-dhcpv4-reconfigure-00.txt, June 1999. 468 [15] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 469 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 470 1997. 472 [16] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 473 RFC 1661, July 1994. 475 [17] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 476 "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 478 [18] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994. 480 [19] Townsley, W.M., Valencia, A., Rubens, A., Pall, G.S., Zorn, G., and 481 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 482 1999. 484 [20] Valencia, A. J., "L2TP Header Compression (``L2TPHC'')", Internet 485 draft (work in progress), draft-ietf-l2tpext-l2tphc-03.txt, October 486 1999. 488 [21] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., 489 Beser, B., Privat, J., "The User Class Option for DHCP", Internet 490 draft (work in progress), draft-ietf-dhc-userclass-04.txt, October 491 1999. 493 [22] Perkins, C., "Minimal Encapsulation Within IP", RFC 2004, October 494 1996. 496 [23] Degermark, M., Nordgren, B., Pink, S., "IP Header Compression", RFC 497 2507, February 1999. 499 [24] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for 500 Low-Speed Serial Links", RFC 2508, February 1999. 502 [25] Engan, M., Casner, S. and C. Bormann, "IP Header Compression for 503 PPP", RFC 2509, February 1999. 505 [26] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, 506 G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 507 1999. 509 [27] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 511 [28] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 512 ietf-radius-ext-04.txt, Internet Draft (work in progress), May 513 1999. 515 [29] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 516 (EAP)", RFC 2284, March 1998. 518 [30] Myers, J., "Simple Authentication and Security Layer (SASL)", FC 519 2222, October 1997. 521 [31] Linn, J., "Generic Security Service Application Program Interface, 522 Version 2", RFC 2078, January 1997. 524 [33] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 525 (V5)", RFC 1510, September 1993. 527 [34] Neuman, B. C., Ts'o, T., "Kerberos: An Authentication Service for 528 Computer Networks", IEEE Communications, 32(9):33-38, September 529 1994. 531 [35] Tung, B., Neuman, B. C., Hur, M., Medvinsky, A., Medvinsky, S., 532 Wray, J., Trostle, J., "Public Key Cryptography for Initial 533 Authentication in Kerberos", Internet draft (work in progress), 534 draft-ietf-cat-kerberos-pk-init-08.txt, May 1999. 536 [36] Baize, E., Pinkas., D., "The Simple and Protected GSS-API 537 Negotiation Mechanism", RFC 2478, December 1998. 539 [37] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 540 June 1996. 542 [38] Myers, J., "SASL GSSAPI mechanisms", Internet draft (work in 543 progress), draft-ietf-cat-sasl-gssapi-00.txt, March 1999. 545 [39] Piper, D., "A GSS-API Authentication Mode for IKE", Internet draft 546 (work in progress), draft-ietf-ipsec-isakmp-gss-auth-02.txt, 547 December 1998. 549 [40] Lloyd, B., Simpson, W., "PPP Authentication Protocols", RFC 1334, 550 October 1992. 552 [41] Swift, M., Trostle, J., "Initial Authentication and Pass Through 553 Authentication Using Kerberos V5 and the GSS-API (IAKERB)", 554 Internet draft (work in progress), draft-ietf-cat-iakerb-04.txt, 555 October 1999. 557 [42] Pereira, R., Beaulieu, S., "Extended Authentication within 558 ISAKMP/Oakley", Internet-draft (work in progress), draft-ietf- 559 ipsec-isakmp-xauth-05.txt, September, 1999. 561 8. Security Considerations 563 This document, being a requirements document, does not have any security 564 concerns. The security requirements on protocols to be evaluated using 565 this document are described throughout the document. 567 9. IANA Considerations 569 This draft does not create any new number spaces for IANA 570 administration. 572 10. Acknowledgments 574 Thanks to Scott Kelly of Redcreek Communications and Ari Huttunen of 575 Data Fellows for useful discussions of this problem space. 577 11. Authors' Addresses 579 Bernard Aboba 580 Microsoft Corporation 581 One Microsoft Way 582 Redmond, WA 98052 584 Phone: +1 (425) 936-6605 585 EMail: bernarda@microsoft.com 587 12. Full Copyright Statement 589 Copyright (C) The Internet Society (2000). All Rights Reserved. 590 This document and translations of it may be copied and furnished to 591 others, and derivative works that comment on or otherwise explain it or 592 assist in its implementation may be prepared, copied, published and 593 distributed, in whole or in part, without restriction of any kind, 594 provided that the above copyright notice and this paragraph are included 595 on all such copies and derivative works. However, this document itself 596 may not be modified in any way, such as by removing the copyright notice 597 or references to the Internet Society or other Internet organizations, 598 except as needed for the purpose of developing Internet standards in 599 which case the procedures for copyrights defined in the Internet 600 Standards process must be followed, or as required to translate it into 601 languages other than English. The limited permissions granted above are 602 perpetual and will not be revoked by the Internet Society or its 603 successors or assigns. This document and the information contained 604 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 605 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 606 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 607 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 610 13. Expiration Date 612 This memo is filed as , and expires 613 August 1, 2001.