idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-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: ---------------------------------------------------------------------------- ** 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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. 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.) -- The document date (November 17, 1999) is 8924 days in the past. Is this intentional? 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: 'ArchSec' is mentioned on line 141, but not defined == Missing Reference: 'Thayer97' is mentioned on line 141, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 146, but not defined == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-02 -- Possible downref: Normative reference to a draft: ref. 'DIAMETER' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-isakmp-hybrid-auth-01 -- Possible downref: Normative reference to a draft: ref. 'HYBRID' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- No information found for draft-ietf-ipsec-isakmp-cfg - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IKECFG' ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1938 (ref. 'OTP') (Obsoleted by RFC 2289) ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'SKEY') ** Downref: Normative reference to an Informational RFC: RFC 1492 (ref. 'TACACS') Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Security Working Group S. Beaulieu 3 Internet Draft TimeStep Corporation 4 Expires November 17, 1999 5 May 17, 1999 7 Extended Authentication within ISAKMP/Oakley 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 This document is a submission to the IETF Internet Protocol 16 Security (IPSECond) Working Group. Comments are solicited and 17 should be addressed to the working group mailing list 18 (ipsec@lists.tislabs.com) or to the editor. 20 This document is an Internet-Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working Groups. Note that other groups may also distribute 23 working documents as Internet Drafts. 25 Internet-Drafts draft documents are valid for a maximum of six 26 months and may be updated, replaced, or made obsolete by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To learn the current status of any Internet-Draft, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 Distribution of this memo is unlimited. 45 Copyright Notice 47 Copyright (C) The Internet Society (1998-1999). All Rights 48 Reserved. 50 Internet Draft May-99 52 Abstract 54 This document describes a method for using existing unidirectional 55 authentication mechanisms such as RADIUS, SecurID, and OTP within 56 IPSec's ISAKMP protocol. 58 Table of Contents 60 1 Introduction.......................................................2 61 1.1 Changes Since Last Revision......................................3 62 1.2 Extended Authentication..........................................3 63 1.3 Reader Prerequisites.............................................3 64 1.4 Specification of Requirements....................................4 65 2 Extended Authentication Method.....................................4 66 2.1 Simple Authentication............................................5 67 2.2 Challenge/Response...............................................5 68 2.3 Two-Factor Authentication........................................6 69 2.4 One-Time-Password................................................7 70 2.5 User Previously Authenticated....................................7 71 3 Extensions to ISAKMP-Config........................................7 72 3.1 Message Types....................................................8 73 3.2 Attributes.......................................................9 74 3.3 Authentication Types............................................10 75 4 Authentication Method Types.......................................11 76 5 Other Scenarios for Extended Authentication.......................13 77 6 Security Considerations...........................................13 78 7 References........................................................13 79 8 Acknowledgements..................................................14 80 9 Authors� Addresses................................................15 81 10 Expiration.......................................................15 82 11 Full Copyright Statement.........................................15 84 1 Introduction 86 The following technique allows IPSec's ISAKMP/Oakley [IKE] protocol 87 to support extended authentication mechanisms like two-factor 88 authentication, challenge/response and other remote access 89 unidirectional authentication methods. 91 These authentication mechanisms have a large deployment in remote 92 access applications and many IT departments have requirements for 93 these unidirectional authentication mechanisms. 95 Internet Draft May-99 97 1.1 Changes Since Last Revision 99 o The last revision of this document was published in the IPSec 100 Working Group as 101 103 o Some text was added to describe how to separate phase 1 rekeying 104 and Extended Authentication. 106 o Isakmp authentication method values were defined for Extended 107 Authentication. 109 o A correction was made in the RADIUS challenge example. RADIUS 110 uses the Message Attribute to transmit a challenge, unless it is a 111 CHAP challenge. 113 o Added more emphasis on using GENERIC type whenever possible. 115 1.2 Extended Authentication 117 Two-factor authentication and challenge/response schemes like SDI's 118 SecurID and RADIUS are forms of authentication that allow a 119 gateway, firewall, or network access server to offload the user 120 administration and authentication to a central management server. 121 IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 122 shared-secret, and Kerberos as authentication methods, but since 123 the authentication methods described within this document are only 124 unidirectional authentication methods (client to a 125 gateway/firewall), they cannot be used by themselves, but must be 126 used in conjunction with the other standard ISAKMP authentication 127 methods. 129 The technique described within this document utilizes ISAKMP to 130 transfer the user's authentication information (name, password) to 131 the gateway/firewall (edge device) in a secured ISAKMP message. The 132 edge device would then use either the appropriate protocol (RADIUS, 133 SecurID, OTP) to authenticate the user. This allows the 134 authentication server to be within the private network that the 135 edge device is protecting. 137 1.3 Reader Prerequisites 139 It is assumed that the reader is familiar with the terms and 140 concepts described in the "Security Architecture for the Internet 141 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 142 documents. 144 Internet Draft May-99 146 Readers are advised to be familiar with both [IKE] and [ISAKMP] as 147 well as [IKECFG] since this document is an extension to that 148 document. 150 1.4 Specification of Requirements 152 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 153 NOT", and "MAY" that appear in this document are to be interpreted 154 as described in [Bradner97]. 156 2 Extended Authentication Method 158 This specification allows for extended authentication by allowing 159 an edge device to request extended authentication from an IPSec 160 host (end-node), thus forcing the host to respond with its extended 161 authentication credentials. The edge device will then respond with 162 a failed or passed message. 164 When the edge device requests extended authentication, it will 165 specify the type of extra authentication and any parameters 166 required for it. These parameters MAY be the attributes that it 167 requires for authentication and they MAY be information required 168 for the IPSec host's reply (e.g. challenge string). 170 The last message sent by the edge device is simply a reply denoting 171 failure or success. The reply MAY have some textual information 172 describing the reason for the failure or success. The edge device 173 MAY also request another authentication, like SecurID's next PIN 174 request, where the user is required to enter the next passcode to 175 further verify itself. 177 As with CHAP [CHAP], this protocol can also be used to periodically 178 authenticate the user during the lifetime of a security 179 association. 181 If the IPSec host does not have support for the authentication 182 method requested by the edge device, then it would send back a 183 reply with empty attributes, thus failing the authentication but 184 completing the transaction. The last exchange (SET/ACK) MUST also 185 be completed. 187 The Extended Authentication mechanism does not replace the IKE 188 Phase 1 authentication mechanisms. It simply extends them by 189 allowing devices to do two different authentication schemes. Both 190 peers SHOULD still authenticate themselves via the authentication 191 methods described in [IKE]. 193 Internet Draft May-99 195 This method provides unidirectional authentication only, meaning 196 that only one device is authenticated using both IKE authentication 197 methods and Extended Authentication. 199 Here are some types of extended authentication that this 200 specification supports; 202 2.1 Simple Authentication 204 Where a user name and password are required for authentication. 206 IPSec Host Edge Device 207 -------------- ----------------- 208 <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="") 209 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar") --> 210 <-- SET(STATUS=OK) 211 ACK(STATUS) --> 213 Some authentication mechanisms hide the user password by some type 214 of encryption mechanism. 216 IPSec Host Edge Device 217 -------------- ----------------- 218 <-- REQUEST(TYPE=RADIUS CHALLENGE="123456" 219 NAME="" PASSWORD="") 220 REPLY(TYPE=RADIUS NAME="joe" PASSWORD="E4901AB7") --> 221 <-- SET(STATUS=OK) 222 ACK(STATUS) --> 224 2.2 Challenge/Response 226 Where a challenge from the edge device must be incorporated with 227 the reply. This makes each reply different. 229 IPSec Host Edge Device 230 -------------- ----------------- 231 <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="") 232 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar") --> 233 <-- REQUEST(TYPE=GENERIC MESSAGE="Enter your password 234 followed by your pin number" NAME="" PASSWORD="" REQ_NUM=2) 235 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") --> 236 <-- SET(STATUS=OK) 237 ACK(STATUS) --> 239 If, however, the edge device knows that a challenge will be 240 required it may skip the first exchange as follows: 242 Internet Draft May-99 244 IPSec Host Edge Device 245 -------------- ----------------- 246 <-- REQUEST(TYPE=GENERIC MESSAGE="Enter your password 247 followed by your pin number" NAME="" PASSWORD="") 248 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") --> 249 <-- SET(STATUS=OK) 250 ACK(STATUS) --> 252 2.3 Two-Factor Authentication 254 This authentication method combines something the user knows (their 255 password) and something that the user has (a token card). 257 IPSec Host Edge Device 258 -------------- ----------------- 259 <-- REQUEST(TYPE=GENERIC NAME="" 260 PASSWORD="" PASSCODE="") 261 REPLY(TYPE=GENERIC NAME="joe" 262 PASSWORD="foobar" PASSCODE="3412") --> 263 <-- SET(STATUS=OK) 264 ACK(STATUS) --> 266 Some mechanisms allow for another optional request of the passcode. 268 IPSec Host Edge Device 269 -------------- ----------------- 270 <-- REQUEST(TYPE=GENERIC NAME="" 271 PASSWORD="" PASSCODE="") 272 REPLY(TYPE=GENERIC NAME="joe" 273 PASSWORD="foobar" PASSCODE="323415") --> 274 <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="" 275 PASSCODE="" REQ_NUM=2) 276 REPLY(TYPE=GENERIC NAME="joe" 277 PASSWORD="foobar" PASSCODE="513212") --> 278 <-- SET(STATUS=OK) 279 ACK(STATUS) --> 281 Internet Draft May-99 283 2.4 One-Time-Password 285 Similar to the Challenge/Response method, this method allows 286 authentication that is secure against passive attacks based on 287 replaying captured passwords. 289 IPSec Host Edge Device 290 -------------- ----------------- 291 <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" 292 NAME="" PASSWORD="") 293 REPLY(TYPE=OTP NAME="joe" 294 PASSWORD="5bf0 75d9 959d 036f") --> 295 <-- SET(STATUS=OK) 296 ACK(STATUS) --> 298 2.5 User Previously Authenticated 300 Some situations may occur where the edge device has already 301 authenticated the host and no new authentication is required. This 302 may happen when either the host or the edge device must rekey an 303 existing phase 1 SA. The edge device is not sure who the peer is 304 because the phase 1 ID is not transmitted until after the proposal 305 payloads are exchange. In this case, the peers may agree to do 306 XAUTH even though the remote user still has a valid XAUTH 307 authentication. In such a scenario, this method MAY be used to 308 avoid prompting the user. Edge devices MUST NOT use this 309 authentication method in cases where the phase 1 ID does not match 310 the previous phase 1 ID. 312 In these situations, the following method is used. 314 IPSec Host Edge Device 315 ------------- ---------------- 316 <-- SET(STATUS=OK) 317 ACK(STATUS) --> 319 3 Extensions to ISAKMP-Config 321 This protocol uses the mechanisms described in ISAKMP-Config 322 [IKECFG] to accomplish its authentication transaction. 324 All ISAKMP-Config messages in an extended authentication 325 transaction MUST contain the same ISAKMP-Config message ID. 327 This protocol can therefore be used in conjunction with any 328 existing basic ISAKMP authentication method as defined in [IKE]. 330 Internet Draft May-99 332 If mutual authentication is not required, then the phase 1 333 negotiation MAY use an authentication method of shared-secret and 334 have that shared-secret be null. However, this is STRONGLY 335 DISCOURAGED since the edge-device is NOT authenticated. See the 336 Security Considerations section for more detail. 338 This authentication MUST be used after a phase 1 exchange has 339 completed and before any other exchange with the exception of Info 340 mode exchanges. If the extended authentication fails, then the 341 phase 1 SA MUST be immediately deleted. 343 Extended Authentication MAY be initiated by the edge device at any 344 time after the initial authentication exchange. For example, 345 RADIUS servers may specify that a user only be authenticated for a 346 certain time period. Once that time period has elapsed (minus a 347 possible jitter), the edge device may request a new Extended 348 Authentication exchange with initiating a new phase 1 exchange. If 349 the Extended Authentication exchange fails, the edge device MUST 350 tear down all phase 1 and phase 2 SAs associated with the user. 352 The following are extensions to the ISAKMP-Config [IKECFG] 353 specification to support Extended Authentication. 355 3.1 Message Types 357 Type Value 358 -------------------------- ----------------------------- 359 ISAKMP_CFG_REQUEST ( as defined in [IKECFG] ) 360 ISAKMP_CFG_REPLY ( as defined in [IKECFG] ) 361 ISAKMP_CFG_SET ( as defined in [IKECFG] ) 362 ISAKMP_CFG_ACK ( as defined in [IKECFG] ) 364 o ISAKMP_CFG_REQUEST - This message is sent from an edge device to 365 an IPSec host trying to request extended authentication. 366 Attributes that it requires sent back in the reply MUST be 367 included with a length of zero (0). Attributes required for the 368 authentication reply, such as a challenge string MUST be included 369 with the proper values filled in. 371 o ISAKMP_CFG_REPLY - This message MUST contain the filled in 372 authentication attributes that were requested by the edge device. 374 o ISAKMP_CFG_SET - This message is sent from an edge device and is 375 only used, within the scope of this document, to state the 376 success of the authentication. This message MUST only include 377 the success of failure of the authentication and MAY contain some 378 clarification text. 380 o ISAKMP_CFG_ACK - This message is sent from the IPSec host 382 Internet Draft May-99 384 acknowledging receipt of the authentication result. Its 385 attributes are not relevant and MAY be skipped entirely, thus not 386 attributes SHOULD be included. This last message in the 387 authentication transaction is used solely as an acknowledgement 388 of the previous message and to eliminate problems with 389 unacknowledged messages over UDP. 391 3.2 Attributes 393 Attribute Value Type 394 --------------------- ------ --------------------- 395 XAUTH_TYPE 13 Basic 396 XAUTH_USER_NAME 14 Variable ASCII string 397 XAUTH_USER_PASSWORD 15 Variable ASCII string 398 XAUTH_PASSCODE 16 Variable ASCII string 399 XAUTH_MESSAGE 17 Variable ASCII string 400 XAUTH_CHALLENGE 18 Variable ASCII string 401 XAUTH_DOMAIN 19 Variable ASCII string 402 XAUTH_STATUS 20 Basic 403 XAUTH_REQ_NUMBER 21 Basic 405 o XAUTH_TYPE - The type of extended authentication requested whose 406 values are described in the next section. This is a mandatory 407 attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY 408 messages. 410 o XAUTH_USER_NAME - The user name MAY be any unique identifier of 411 the user such as a login name, an email address, or a X.500 412 Distinguished Name. 414 o XAUTH_USER_PASSWORD - The user's password. 416 o XAUTH_PASSCODE - A token card's passcode. This SHOULD only be 417 used when the password attribute is also used. 419 o XAUTH_MESSAGE - A textual message from an edge device to an IPSec 420 host. The message may contain a textual challenge or 421 instruction. An example of this would be "Enter your password 422 followed by your pin number". The message may also contain a 423 reason why authentication failed or succeeded. This message 424 SHOULD be displayed to the user. 426 o XAUTH_CHALLENGE - A challenge string sent from the edge device to 427 the IPSec host for it to include in its calculation of a 428 password. This attribute SHOULD only be sent in an 429 ISAKMP_CFG_REQUEST message. Typically, the XAUTH_TYPE attribute 430 dictates how the receiving device should handle the challenge. 431 For example, RADIUS uses the challenge to hide the password. 433 Internet Draft May-99 435 o XAUTH_DOMAIN - The domain to be authenticated in. This value 436 will have different meaning depending on the authentication type. 438 o XAUTH_STATUS - A variable that is used to denote authentication 439 success (OK=1) or failure (FAIL=0). This is a mandatory 440 attribute for the ISAKMP_CFG_SET message. 442 o XAUTH_REQ_NUMBER - The number of times that a request has been 443 made, including the current request. The default value is one 444 (1) and thus does not have to be included. This attribute is 445 used to denote that an authentication transaction has had to have 446 another authentication request. The IPSec host should notice 447 that this is not a retransmit of the original request, but that 448 this is yet another request. This attribute MUST only be 449 included in the ISAKMP_CFG_REQUEST message. 451 3.3 Authentication Types 453 Value Authentication Required 454 ----- --------------------------------- 455 0 Generic 456 1 RADIUS 457 2 OTP 458 3 NT Domain 459 4 Unix Login 460 5 SDI SecurID 461 6 AXENT Defender 462 7 LeeMah InfoCard 463 8 ActiveCard 464 9 Secure Computing Enigma (DES Gold) 465 10 TACACS 466 11 TACACS+ 467 12 S/KEY 468 13 NDS (Netware Directory Services) 469 14 DIAMETER 470 15 LDAP 471 16-32767 Reserved for future use 472 32768-65535 Reserved for private use 474 o Generic - A catch-all type that allows for future extensibility 475 and a generic mechanism to request authentication information. 476 This method allows for any type of extended authentication which 477 does not require specific processing, and should be used whenever 478 possible. 480 o RADIUS - A RADIUS [RADIUS] server requires at least a user name 481 and a password, but since RADIUS may be proxying for another type 482 of authentication method, both the request and the reply MAY be 484 Internet Draft May-99 486 like any of the other extended authentication types. 488 o OTP - One-Time-Passwords as defined in [OTP] uses a challenge 489 string to request a certain generated password. The request 490 SHOULD contain a user name, password and a challenge string while 491 the reply MUST contain the user name and the generated password. 492 The challenge string is formatted as defined in [OTPEXT]. 494 o NT Domain - This authentication type provides for user 495 authentication by login into a Windows NT(r) domain. The request 496 SHOULD contain empty user name, password and domain attributes. 497 The reply MUST contain all of these attributes filled in. The 498 domain attribute is optional for both messages, and SHOULD NOT be 499 included in the reply if it isn�t included in the request. 501 o Unix Login - Much like the NT Domain authentication type, but 502 this will authenticate the user to a Unix(r) workstation. 504 o SDI SecurID, AXENT Defender, LeeMah InfoCard, ActiceCard, 505 Enigma/DES Gold - All of these (and others) use smart cards to 506 generate a 'passcode' to authenticate the user. This passcode 507 combined with the user's password provides stronger 508 authentication than just passwords. The response MUST include 509 the user name, password and the token card's passcode. This 510 authentication type MIGHT also include a challenge string in the 511 request. 513 o TACACS - Defined in [TACACS], this authentication protocol was 514 the precursor to RADIUS, thus the same rules apply. 516 o TACACS+ - Defined in [TACACS+], this authentication protocol is 517 an updated version of the original TACACS protocol, thus the same 518 rules apply. 520 o S/KEY - This one-time-password scheme defined in [SKEY] was the 521 precursor to OTP, thus the same rules applies. 523 o NDS - Much like the NT Domain authentication type, but this will 524 authenticate the user to a NetWare Directory server. 526 o DIAMETER - The next generation RADIUS protocol that is defined in 527 [DIAMETER]. The same rules as RADIUS apply. 529 4 Authentication Method Types 531 The following values relate to the ISAKMP authentication method 532 attribute used in proposals. They optionally allow an XAUTH 533 implementation to propose use of extended authentication after the 535 Internet Draft May-99 537 initial phase 1 authentication. Values are taken from the private 538 use range defined in [IKE] and should be used among mutually 539 consenting parties. 541 Method Value 542 ------------------------------ ----- 543 XAUTHInitPreShared 65001 544 XAUTHRespPreShared 65002 545 XAUTHInitDSS 65003 546 XAUTHRespDSS 65004 547 XAUTHInitRSA 65005 548 XAUTHRespRSA 65006 549 XAUTHInitRSAEncryption 65007 550 XAUTHRespRSAEncryption 65008 551 XAUTHInitRSARevisedEncryption 65009 552 XAUTHRespRSARevisedEncryption 65010 554 An Extended Authentication proposal has two characteristics. 556 The first is the direction of the authentication. Each type 557 identifies whether the Initiator or the Resonder is the device 558 which should be authenticated using XAUTH. For example 559 XAUTHInitPreShared is a type which demands that the Initiator be 560 authenticated. 562 Note that an edge device would typically initiate with one of the 563 following: 564 o XAUTHRespPreShared 565 o XAUTHRespDSS 566 o XAUTHRespRSA 567 o XAUTHRespRSAEncryption 568 o XAUTHRespRSARevisedEncryption 570 and would typically only accept proposals with the following 571 authentication methods: 572 o XAUTHInitPreShared 573 o XAUTHInitDSS 574 o XAUTHInitRSA 575 o XAUTHInitRSAEncryption 576 o XAUTHInitRSARevisedEncryption 578 The second characteristic is the IKE Authentication method to be 579 used. The following table illustrates which keywords in the 580 methods described above relate to which Authentication Methods 581 described in [IKE] Appendix A. 583 Internet Draft May-99 585 "PreShared" -> pre-shared key 586 "DSS" -> DSS signatures 587 "RSA" -> RSA signatures 588 "RSAEncryption" -> Encryption with RSA 589 "RSARevisedEncryption" -> Revised encryption with RSA 591 5 Other Scenarios for Extended Authentication 593 Although this document described a scenario where an IPSec host 594 (eg. mobile user) was being authenticated by an edge device (eg. 595 firewall/gateway), the methods described can also be used for edge 596 device to edge device authentication as well as IPSec host to IPSec 597 host authentication. 599 6 Security Considerations 601 Care should be taken when sending sensitive information over public 602 networks such as the Internet. A user's password should never be 603 sent in the clear and when sent encrypted, the destination MUST 604 have been previously authenticated. The use of ISAKMP-Config 605 [IKECFG] addresses these issues. 607 The use of Extended Authentication does not imply that phase 1 608 authentication is no longer needed. Phase 1 authentication provides 609 a higher level of user authentication by signing ISAKMP packets. 610 Extended Authentication does not provide this service. The removal 611 of phase 1 authentication would leave the IPSec session vulnerable 612 to a man-in-the-middle attack and other spoofing attacks. 614 7 References 616 [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate 617 Requirement Levels", RFC2119 619 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication 620 Protocol (CHAP)", RFC1994 622 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 623 draft-calhoun-diameter-02.txt 625 [HYBRID] M. Litvin, R. Shamir, T. Zegman, "A Hybrid 626 Authentication Mode for IKE", draft-ietf-ipsec- 627 isakmp-hybrid-auth-01 629 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 630 (IKE)", RFC2409 632 Internet Draft May-99 634 [IKECFG] R. Pereira, "The ISAKMP Configuration Method", 635 draft-ietf-ipsec-isakmp-cfg-03 637 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, 638 "Remote Authentication Dial In User Service 639 (RADIUS)", RFC2138 641 [OTP] N. Haller, C. Metz, "A One-Time Password System", 642 RFC1938 644 [SKEY] N. Haller, "The S/KEY One-Time Password System", 645 RFC1760 647 [TACACS] C. Finseth, "An Access Control Protocol, Sometimes 648 Called TACACS", RFC1492 650 [TACACS+] D. Carrel, L. Grant, "The TACACS+ Protocol Version 651 1.77", draft-grant-tacacs-01.txt 653 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 655 8 Acknowledgements 657 The internet-draft "A Hybrid Authentication Mode for IKE" helped us further enhance 659 this specification. The concept of using new Authentication Method 660 identifiers in the SA payload in order to accomplish extended 661 authentication originated in the [HYBRID] draft. 663 Internet Draft May-99 665 9 Authors' Addresses 667 Roy Pereira 668 669 TimeStep Corporation 670 +1 (613) 599-3610 x 4808 672 Stephane Beaulieu 673 674 TimeStep Corporation 675 +1 (613) 599-3610 x 4709 677 The IPSec working group can be contacted via the IPSec working 678 group's mailing list (ipsec@tis.com) or through its chairs: 680 Robert Moskowitz 681 rgm@icsa.net 682 Internal Computer Security Association 684 Theodore Y. Ts'o 685 tytso@MIT.EDU 686 Massachusetts Institute of Technology 688 10 Expiration 690 This draft expires November 17, 1999 692 11 Full Copyright Statement 694 Copyright (C) The Internet Society (1998). All Rights Reserved. 696 This document and translations of it may be copied and furnished to 697 others, and derivative works that comment on or otherwise explain 698 it or assist in its implementation may be prepared, copied, 699 published and distributed, in whole or in part, without restriction 700 of any kind, provided that the above copyright notice and this 701 paragraph are included on all such copies and derivative works. 702 However, this document itself may not be modified in any way, such 703 as by removing the copyright notice or references to the Internet 704 Society or other Internet organizations, except as needed for the 705 purpose of developing Internet standards in which case the 706 procedures for copyrights defined in the Internet Standards process 707 must be followed, or as required to translate it into languages 708 other than English. 710 The limited permissions granted above are perpetual and will not be 711 revoked by the Internet Society or its successors or assigns. 713 Internet Draft May-99 715 This document and the information contained herein is provided on 716 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 717 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 718 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 719 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 720 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.