idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-06.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. == 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. ** The abstract seems to contain references ([IKE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 1999) is 8898 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 155, but not defined == Missing Reference: 'Thayer97' is mentioned on line 155, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 174, but not defined == Unused Reference: 'DIAMETER' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'TACACS' is defined on line 751, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ike-base-mode-01 -- Possible downref: Normative reference to a draft: ref. 'BASE' == 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-02 -- Possible downref: Normative reference to a draft: ref. 'HYBRID' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-ike-00 -- Possible downref: Normative reference to a draft: ref. 'IKEv2' -- 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 (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Secure Remote Access Working Group Cisco Systems 3 Internet Draft S. Beaulieu 4 Expires May 2000 TimeStep Corporation 5 December 1999 7 Extended Authentication within ISAKMP/Oakley (XAUTH) 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 Secure 16 Remote Access (IPSRA) Working Group. Comments are solicited and 17 should be addressed to the working group mailing list (ietf- 18 ipsra@vpnc.org) 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 Dec-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. The purpose of this draft is not to 57 replace or enhance the existing authentication mechanisms described 58 in [IKE], but rather to allow them to be extended using legacy 59 authentication mechanisms. 61 Table of Contents 63 1 Introduction.......................................................2 64 1.1 Changes Since Last Revision......................................3 65 1.2 Extended Authentication..........................................3 66 1.3 Reader Prerequisites.............................................4 67 1.4 Specification of Requirements....................................4 68 2 Vendor ID..........................................................4 69 3 Extended Authentication Method.....................................4 70 3.1 Simple Authentication............................................6 71 3.2 Challenge/Response...............................................6 72 3.3 Two-Factor Authentication........................................7 73 3.4 One-Time-Password................................................7 74 3.5 User Previously Authenticated....................................8 75 3.6 Other Useful Examples............................................8 76 4 Extensions to ISAKMP-Config........................................9 77 4.1 Message Types....................................................9 78 4.2 Attributes......................................................10 79 4.3 Authentication Types............................................11 80 5 Authentication Method Types.......................................12 81 6 Other Scenarios for Extended Authentication.......................13 82 7 Extensibility.....................................................13 83 8 Security Considerations...........................................14 84 9 References........................................................15 85 10 Acknowledgements.................................................16 86 11 Authors' Addresses...............................................17 87 11 Expiration.......................................................17 88 12 Full Copyright Statement.........................................17 89 Appendix A..........................................................19 91 1 Introduction 93 The following technique allows IPSec's ISAKMP/Oakley [IKE] protocol 94 to support extended authentication mechanisms like two-factor 96 Internet Draft Dec-99 98 authentication, challenge/response and other remote access 99 unidirectional authentication methods. 101 These authentication mechanisms have a large deployment in remote 102 access applications and many IT departments have requirements for 103 these unidirectional authentication mechanisms. 105 1.1 Changes Since Last Revision 107 o The last revision of this document was published in the IPSec 108 Working Group as 109 111 o Moved XAUTH Attribute ID numbers to private range of Isakmp- 112 Config draft to avoid future collisions. 114 o Added a Feature / Vendor ID. 116 o Removed all of the authentication types which can use Generic. 118 o Made XAUTH_TYPE optional, with the default set to Generic if not 119 present. 121 o Clarified the text which allows for a remote peer to abort in the 122 middle of a transaction. 124 o Expanded on Security Considerations. 126 1.2 Extended Authentication 128 Two-factor authentication and challenge/response schemes like SDI's 129 SecurID and RADIUS are forms of authentication that allow a 130 gateway, firewall, or network access server to offload the user 131 administration and authentication to a central management server. 132 IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 133 shared-secret, and Kerberos as authentication methods, but since 134 the authentication methods described within this document are only 135 unidirectional authentication methods (client to a 136 gateway/firewall), they cannot be used by themselves, but must be 137 used in conjunction with the other standard ISAKMP authentication 138 methods. 140 The technique described within this document utilizes ISAKMP to 141 transfer the user's authentication information (name, password) to 142 the gateway/firewall (edge device) in a secured ISAKMP message. The 143 edge device would then use either the appropriate protocol (RADIUS, 145 Internet Draft Dec-99 147 SecurID, OTP) to authenticate the user. This allows the 148 authentication server to be within the private network that the 149 edge device is protecting. 151 1.3 Reader Prerequisites 153 It is assumed that the reader is familiar with the terms and 154 concepts described in the "Security Architecture for the Internet 155 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 156 documents. 158 Readers are advised to be familiar with both [IKE] and [ISAKMP] as 159 well as [IKECFG] since this document is an extension to that 160 document. 162 1.4 Specification of Requirements 164 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 165 NOT", and "MAY" that appear in this document are to be interpreted 166 as described in [Bradner97]. 168 2 Vendor ID 170 XAUTH currently uses attribute numbers from the private ranges of 171 both [IKE] and [IKECFG]. In order to ensure interoperability with 172 future and past implementations of XAUTH a Vendor ID has been 173 added. The Vendor ID payload is sent during the phase 1 exchange 174 as per [ISAKMP]. The Vendor ID for this revision of XAUTH is a 175 truncated MD5 hash of the following ASCII text string: "draft-ietf- 176 ipsra-isakmp-xauth-06.txt" without the quotation marks. 178 Vendor ID = 0x09002689DFD6B712 180 If an implementation receives the aforementioned Vendor ID, it can 181 assume that the peer also has implemented this protocol and 182 therefore is a "mutually consenting party". 184 If this document advances to the standard-track, then new numbers 185 will be assigned by IANA from the appropriate number spaces of 186 [IKE] and [IKECFG], thus eliminating the need for a Vendor ID 187 payload. 189 3 Extended Authentication Method 191 This specification allows for extended authentication by allowing 192 an edge device to request extended authentication from an IPSec 194 Internet Draft Dec-99 196 host (end-node), thus forcing the host to respond with its extended 197 authentication credentials. The edge device will then respond with 198 a failed or passed message. 200 When the edge device requests extended authentication, it will 201 specify the type of extra authentication and any parameters 202 required for it. These parameters MAY be the attributes that it 203 requires for authentication and they MAY be information required 204 for the IPSec host's reply (e.g. challenge string). 206 The Extended Authentication transaction is terminated either when 207 the edge device starts a SET/ACK exchange which includes an 208 XAUTH_STATUS attribute or when the remote device sends a 209 XAUTH_STATUS attribute in a REPLY message. Please note that a 210 remote device can not set XAUTH_STATUS to anything but FAIL. 212 The edge device MAY request multiple different authentication 213 transactions within one Extended Authentication transaction. This 214 is done by having multiple REQUEST/REPLY pairs, initiated by the 215 edge device, before the transaction is terminated as described 216 above. Each REQUEST/REPLY pair MAY have a different value for 217 XAUTH_TYPE. 219 As with CHAP [CHAP], this protocol can also be used to periodically 220 authenticate the user during the lifetime of a security 221 association. 223 If the IPSec host does not have support for the authentication 224 method requested by the edge device, then it would send back a 225 REPLY with the XAUTH_STATUS attribute set to FAIL, thus failing 226 the authentication but completing the transaction. 228 The Extended Authentication mechanism does not effect the nature of 229 the phase 1 authentication mechanism in any way. Both peers MUST 230 authenticate each other via the authentication methods described in 231 [IKE]. There are Security Considerations involved in one of the 232 authentication methods in [IKE] and this is described in "Security 233 Considerations" below. 235 This method provides unidirectional authentication only, meaning 236 that only one device is authenticated using both IKE authentication 237 methods and Extended Authentication. 239 Here are some types of extended authentication that this 240 specification supports: 242 Internet Draft Dec-99 244 3.1 Simple Authentication 246 Where a user name and password are required for authentication. 248 IPSec Host Edge Device 249 -------------- ----------------- 250 <-- REQUEST(NAME="" PASSWORD="") 251 REPLY(NAME="joe" PASSWORD="foobar") --> 252 <-- SET(STATUS=OK) 253 ACK(STATUS) --> 255 Some authentication mechanisms hide the user password by some type 256 of encryption mechanism. 258 IPSec Host Edge Device 259 -------------- ----------------- 260 <-- REQUEST(TYPE=RADIUS-CHAP CHALLENGE="123456" 261 NAME="" PASSWORD="") 262 REPLY(TYPE=RADIUS-CHAP NAME="joe" PASSWORD="E4901AB7") --> 263 <-- SET(STATUS=OK) 264 ACK(STATUS) --> 266 NOTE: This is a conceptual example of RADIUS-CHAP, for a more 267 detailed example, see Appendix A. 269 3.2 Challenge/Response 271 Where a challenge from the edge device must be incorporated with 272 the reply. This makes each reply different. 274 IPSec Host Edge Device 275 -------------- ----------------- 276 <-- REQUEST(NAME="" PASSWORD="") 277 REPLY(NAME="joe" PASSWORD="foobar") --> 278 <-- REQUEST(MESSAGE="Enter your password followed by 279 your pin number" NAME="" PASSWORD="") 280 REPLY(NAME="joe" PASSWORD="foobar0985124") --> 281 <-- SET(STATUS=OK) 282 ACK(STATUS) --> 284 If, however, the edge device knows that a challenge will be 285 required it may skip the first exchange as follows: 287 Internet Draft Dec-99 289 IPSec Host Edge Device 290 -------------- ----------------- 291 <-- REQUEST(MESSAGE="Enter your password followed by 292 your pin number" NAME="" PASSWORD="") 293 REPLY(NAME="joe" PASSWORD="foobar0985124") --> 294 <-- SET(STATUS=OK) 295 ACK(STATUS) --> 297 3.3 Two-Factor Authentication 299 This authentication method combines something the user knows (their 300 password) and something that the user has (a token card). 302 IPSec Host Edge Device 303 -------------- ----------------- 304 <-- REQUEST(NAME="" 305 PASSWORD="" PASSCODE="") 306 REPLY(NAME="joe" 307 PASSWORD="foobar" PASSCODE="3412") --> 308 <-- SET(STATUS=OK) 309 ACK(STATUS) --> 311 Some mechanisms allow for another optional request of the passcode. 313 IPSec Host Edge Device 314 -------------- ----------------- 315 <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") 316 REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="323415") --> 317 <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") 318 REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="513212") --> 319 <-- SET(STATUS=OK) 320 ACK(STATUS) --> 322 3.4 One-Time-Password 324 Similar to the Challenge/Response method, this method allows 325 authentication that is secure against passive attacks based on 326 replaying captured passwords. 328 IPSec Host Edge Device 329 -------------- ----------------- 330 <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" 331 NAME="" PASSWORD="") 332 REPLY(TYPE=OTP NAME="joe" PASSWORD="5bf0 75d9 959d 036f") --> 333 <-- SET(STATUS=OK) 334 ACK(STATUS) --> 336 Internet Draft Dec-99 338 3.5 User Previously Authenticated 340 Some situations may occur where the edge device has already 341 authenticated the host and no new authentication is required. This 342 may happen when either the host or the edge device must rekey an 343 existing phase 1 SA. It is important that this method not be used, 344 unless the implementation can be sure that the current phase 1 SA 345 was created with the same peer as the initial phase 1 SA, which was 346 previously authenticated using XAUTH. There is currently no way 347 defined to ensure that two separate phase 1 SAs actually belong to 348 the same peer. One method suggested is to use the ID from the 349 phase 1 negotiation (available in Main Mode and Aggressive Mode) 350 but only if the ID is unique to the user and cannot not be forged. 351 This concept is herein referred to as "ID-Checking". 353 Implementation hint: 355 o In order to accomplish ID-Checking for Phase 1 Authenticated 356 With a Pre-Shared Key (as defined in [IKE]), the pre-shared key 357 lookup must be based on the phase 1 ID. Please note that this 358 method only currently works for Aggressive Mode, and may work 359 with modes defined in the future. A static IP address could also 360 be used for shared secret lookup, however, the binding of the 361 user to XAUTH session would have to use the IP address instead of 362 the ID. 364 o In order to accomplish ID-Checking for IKE Phase 1 365 Authenticated With Signatures (as defined in [IKE]), the 366 implementation must ensure that the ID provided in the phase 1 367 exchange matches the ID in the peer's certificate which must be 368 signed by a trusted third party. 370 In the situation where the peer does not require additional 371 authentication, the following method is used. 373 IPSec Host Edge Device 374 ------------- ---------------- 375 <-- SET(STATUS=OK) 376 ACK(STATUS) --> 378 3.6 Other Useful Examples 380 More useful examples are found in Appendix A. 382 Internet Draft Dec-99 384 4 Extensions to ISAKMP-Config 386 This protocol uses the mechanisms described in ISAKMP-Config 387 [IKECFG] to accomplish its authentication transaction. This 388 protocol uses Configuration Attributes from the private range of 389 Isakmp-Config [IKECFG]. To ensure interoperability with past and 390 future versions of Extended Authentication, a Vendor ID is provided 391 in section 2. 393 All ISAKMP-Config messages in an extended authentication 394 transaction MUST contain the same ISAKMP-Config transaction 395 identifier. The Message ID in the ISAKMP header follows the rules 396 defined by the ISAKMP-Config protocol. 398 This protocol can therefore be used in conjunction with any 399 existing basic ISAKMP authentication method as defined in [IKE]. 401 This authentication MUST be used after a phase 1 exchange has 402 completed and before any other exchange with the exception of Info 403 mode exchanges. If the extended authentication fails, then the 404 phase 1 SA MUST be immediately deleted. The edge device MAY choose 405 to retry an extended authentication request if the user failed to 406 be authenticated, but must do so in the same ISAKMP-Config 407 transaction, and MUST NOT send the SET message until the user is 408 authenticated, or until the edge device wishes to stop retrying and 409 fail the user. 411 Extended Authentication MAY be initiated by the edge device at any 412 time after the initial authentication exchange. For example, 413 RADIUS servers may specify that a user only be authenticated for a 414 certain time period. Once that time period has elapsed (minus a 415 possible jitter), the edge device may request a new Extended 416 Authentication exchange. If the Extended Authentication exchange 417 fails, the edge device MUST tear down all phase 1 and phase 2 SAs 418 associated with the user. 420 The following are extensions to the ISAKMP-Config [IKECFG] 421 specification to support Extended Authentication. 423 4.1 Message Types 425 Type Value 426 -------------------------- ----------------------------- 427 ISAKMP_CFG_REQUEST ( as defined in [IKECFG] ) 428 ISAKMP_CFG_REPLY ( as defined in [IKECFG] ) 429 ISAKMP_CFG_SET ( as defined in [IKECFG] ) 430 ISAKMP_CFG_ACK ( as defined in [IKECFG] ) 432 o ISAKMP_CFG_REQUEST - This message is sent from an edge device to 434 Internet Draft Dec-99 436 an IPSec host trying to request extended authentication. 437 Attributes that it requires sent back in the reply MUST be 438 included with a length of zero (0). Attributes required for the 439 authentication reply, such as a challenge string MUST be included 440 with the proper values filled in. 442 o ISAKMP_CFG_REPLY - This message MUST contain the filled in 443 authentication attributes that were requested by the edge device 444 or if the proper authentication attributes can not be retrieved, 445 then this message MUST contain the XAUTH_STATUS attribute with a 446 value of FAIL. 448 o ISAKMP_CFG_SET - This message is sent from an edge device and is 449 only used, within the scope of this document, to state the 450 success of the authentication. This message MUST only include 451 the success of failure of the authentication and MAY contain some 452 clarification text. 454 o ISAKMP_CFG_ACK - This message is sent from the IPSec host 455 acknowledging receipt of the authentication result. Its 456 attributes are not relevant and MAY be skipped entirely, thus no 457 attributes SHOULD be included. This last message in the 458 authentication transaction is used solely as an acknowledgement 459 of the previous message and to eliminate problems with 460 unacknowledged messages over UDP. 462 4.2 Attributes 464 Attribute Value Type 465 --------------------- ------ --------------------- 466 XAUTH_TYPE 16520 Basic 467 XAUTH_USER_NAME 16521 Variable ASCII string 468 XAUTH_USER_PASSWORD 16522 Variable ASCII string 469 XAUTH_PASSCODE 16523 Variable ASCII string 470 XAUTH_MESSAGE 16524 Variable ASCII string 471 XAUTH_CHALLENGE 16525 Variable ASCII string 472 XAUTH_DOMAIN 16526 Variable ASCII string 473 XAUTH_STATUS 16527 Basic 475 o XAUTH_TYPE - The type of extended authentication requested whose 476 values are described in the next section. This is an optional 477 attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY 478 messages. If the XAUTH_TYPE is not present, then it is assumed 479 to be Generic. The XAUTH_TYPE in a REPLY MUST be identical to 480 the XAUTH_TYPE in the REQUEST. If the XAUTH_TYPE was not present 481 in the REQUEST, then it MUST NOT be present in the REPLY. 482 However, an XAUTH transaction MAY have multiple REQUEST/REPLY 483 pairs with different XAUTH_TYPE values in each pair. 485 Internet Draft Dec-99 487 o XAUTH_USER_NAME - The user name MAY be any unique identifier of 488 the user such as a login name, an email address, or a X.500 489 Distinguished Name. 491 o XAUTH_USER_PASSWORD - The user's password. 493 o XAUTH_PASSCODE - A token card's passcode. 495 o XAUTH_MESSAGE - A textual message from an edge device to an IPSec 496 host. The message may contain a textual challenge or 497 instruction. An example of this would be "Enter your password 498 followed by your pin number". The message may also contain a 499 reason why authentication failed or succeeded. This message 500 SHOULD be displayed to the user. 502 o XAUTH_CHALLENGE - A challenge string sent from the edge device to 503 the IPSec host for it to include in its calculation of a 504 password. This attribute SHOULD only be sent in an 505 ISAKMP_CFG_REQUEST message. Typically, the XAUTH_TYPE attribute 506 dictates how the receiving device should handle the challenge. 507 For example, RADIUS-CHAP uses the challenge to hide the password. 509 o XAUTH_DOMAIN - The domain to be authenticated in. This value 510 will have different meaning depending on the authentication type. 512 o XAUTH_STATUS - A variable that is used to denote authentication 513 success (OK=1) or failure (FAIL=0). This attribute MUST be sent 514 in the ISAKMP_CFG_SET message, in which case it may be set to 515 either OK or FAIL, and MAY be sent in a REPLY message by a remote 516 peer, in which case it MUST be set to FAIL. 518 4.3 Authentication Types 520 Value Authentication Required 521 ----- --------------------------------- 522 0 Generic 523 1 RADIUS-CHAP 524 2 OTP 525 3 S/KEY 526 4-32767 Reserved for future use 527 32768-65535 Reserved for private use 529 o Generic - A catch-all type that allows for future extensibility 530 and a generic mechanism to request authentication information. 531 This method allows for any type of extended authentication which 532 does not require specific processing, and should be used whenever 533 possible. This is the default setting if no XAUTH_TYPE is 534 present. 536 Internet Draft Dec-99 538 o RADIUS-CHAP - RADIUS-CHAP is one method of authentication defined 539 in [RADIUS] which uses a challenge to hide the password. In 540 order to use the CHAP functionality defined in [RADIUS], the 541 XAUTH_TYPE MUST be set to RADIUS-CHAP. For all other methods 542 defined in [RADIUS] (i.e. PAP), the XAUTH_TYPE MUST be set to 543 Generic. 545 o OTP - One-Time-Passwords as defined in [OTP] uses a challenge 546 string to request a certain generated password. The request 547 SHOULD contain a user name, password and a challenge string while 548 the reply MUST contain the user name and the generated password. 549 The challenge string is formatted as defined in [OTPEXT]. 551 o S/KEY - This one-time-password scheme defined in [SKEY] was the 552 precursor to OTP, thus the same rules applies. 554 5 Authentication Method Types 556 The following values relate to the ISAKMP authentication method 557 attribute used in proposals. They optionally allow an XAUTH 558 implementation to propose use of extended authentication after the 559 initial phase 1 authentication. Values are taken from the private 560 use range defined in [IKE] and should be used among mutually 561 consenting parties. To ensure interoperability and avoid 562 collisions, a Vendor ID is provided in section 2. 564 Method Value 565 ------------------------------ ----- 566 XAUTHInitPreShared 65001 567 XAUTHRespPreShared 65002 568 XAUTHInitDSS 65003 569 XAUTHRespDSS 65004 570 XAUTHInitRSA 65005 571 XAUTHRespRSA 65006 572 XAUTHInitRSAEncryption 65007 573 XAUTHRespRSAEncryption 65008 574 XAUTHInitRSARevisedEncryption 65009 575 XAUTHRespRSARevisedEncryption 65010 577 An Extended Authentication proposal has two characteristics. 579 The first is the direction of the authentication. Each type 580 identifies whether the Initiator or the Responder is the device 581 which should be authenticated using XAUTH. For example 582 XAUTHInitPreShared is a type which demands that the Initiator be 583 authenticated. 585 Internet Draft Dec-99 587 Note that an edge device would typically initiate with one of the 588 following: 589 o XAUTHRespPreShared 590 o XAUTHRespDSS 591 o XAUTHRespRSA 592 o XAUTHRespRSAEncryption 593 o XAUTHRespRSARevisedEncryption 595 and would typically only accept proposals with the following 596 authentication methods: 597 o XAUTHInitPreShared 598 o XAUTHInitDSS 599 o XAUTHInitRSA 600 o XAUTHInitRSAEncryption 601 o XAUTHInitRSARevisedEncryption 603 The second characteristic is the IKE Authentication method to be 604 used. The following table illustrates which keywords in the 605 methods described above relate to which Authentication Methods 606 described in [IKE] Appendix A. 608 "PreShared" -> pre-shared key 609 "DSS" -> DSS signatures 610 "RSA" -> RSA signatures 611 "RSAEncryption" -> Encryption with RSA 612 "RSARevisedEncryption" -> Revised encryption with RSA 614 6 Other Scenarios for Extended Authentication 616 Although this document described a scenario where an IPSec host 617 (eg. mobile user) was being authenticated by an edge device (eg. 618 firewall/gateway), the methods described can also be used for edge 619 device to edge device authentication as well as IPSec host to IPSec 620 host authentication. 622 7 Extensibility 624 Although this protocol was initially developed for the corporate 625 "Road Warrior" with a dynamic IP address to connect to a corporate 626 Net, there may be certain applications where static IP addresses 627 are used by the "Road Warrior" or where this protocol is used in a 628 non remote-user environment where the IP address is static. There 629 are Security Considerations for certain applications of this 630 protocol in certain deployment scenarios. Please consult the 631 "Security Considerations" section below for more detail. 633 Internet Draft Dec-99 635 [IKE] defines many different ways to authenticate a user and 636 generate keying material. There are two basic phase 1 modes 637 defined: Main Mode and Aggressive Mode. There are also at least 5 638 different authentication schemes which can be used with each mode. 640 New authentication schemes are being developed and surely more will 641 be standardized in the future. Similarly new phase 1 modes are 642 being proposed to address weaknesses or missing functionality in 643 Main Mode and/or Aggressive mode. 645 It is for this reason that XAUTH was designed to be fully 646 extensible. Since XAUTH extends the phase 1 authentication 647 provided by [IKE], it is an important design goal that a legacy 648 user authentication scheme in IPsec be able to use the strengths of 649 current and future authentication and key generation schemes. 651 XAUTH accomplishes this by working with all modes which allow the 652 negotiation of a phase 1 authentication method in ISAKMP. Any new 653 authentication methods defined in the future which are not 654 addressed by this document need simply to take values from the 655 "consenting parties" ranges of [IKE]. Such an example would be the 656 introduction of Encryption with El-Gamal and Revised Encryption 657 with El-Gamal which were introduced in [IKEv2] which is a proposed 658 standard. 660 Furthermore, any new modes defined, such as [HYBRID] and Base Mode 661 [BASE], will automatically be able to use the functionality of 662 XAUTH as no new numbers are needed. 664 Finally, any new or forgotten Legacy User Authentication Schemes 665 which are not part of XAUTH can be easily incorporated by taking 666 numbers from the "consenting parties" ranges of XAUTH, or by 667 requesting reserved numbers from IANA. 669 8 Security Considerations 671 Care should be taken when sending sensitive information over public 672 networks such as the Internet. A user's password should never be 673 sent in the clear and when sent encrypted, the destination MUST 674 have been previously authenticated. The use of ISAKMP-Config 675 [IKECFG] addresses these issues. 677 The protocol described in this memo strictly extends the 678 authentication methods described in [IKE]. It does not in any way 679 affect the authenticated nature of the phase 1 security 680 association. In fact, this protocol heavily relies on the 681 authenticated nature of the phase 1 SA. Without complete phase 1 682 authentication, this protocol does not provide *any* authentication 684 Internet Draft Dec-99 686 at all, since it becomes easily vulnerable to Man-in-the-Middle 687 (MitM) attacks. 689 This protocol was designed to be extensible, and can be used in 690 many possible combinations of phase 1 Modes and authentication 691 methods. However, certain combinations of scenarios could lead to 692 weaker than desired security, and are therefore discouraged. 694 When using XAUTH with Pre-Shared keys, where the peer's IP address 695 is dynamic, Main Mode SHOULD NOT be used, and is STRONGLY 696 DISCOURAGED. In this particular scenario, the phase 1 697 authentication becomes suspect as the administrator has little 698 choice but to use one single Shared-Key for all users, and group- 699 shared keys are susceptible to "social engineering attacks". 701 However, the choice of implementation of this functionality is left 702 up to the implementers of this protocol. There may be some 703 applications where this functionality is desired. Some examples 704 are: proof of concept deployments and small deployments where the 705 proper management of a group shared-key is less difficult. 707 If at some point restrictions are introduced in one of the IPsec 708 Standard RFC documents which prohibit the use of group pre-shared 709 keys, then this protocol will, by default, conform, and these 710 Security Considerations will no longer be of concern. 712 9 References 714 [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate 715 Requirement Levels", RFC2119 717 [BASE] Y. Dayan, S. Bitan, "IKE Base Mode", draft-ietf- 718 ipsec-ike-base-mode-01.txt 720 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication 721 Protocol (CHAP)", RFC1994 723 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 724 draft-calhoun-diameter-02.txt 726 [HYBRID] M. Litvin, R. Shamir, T. Zegman, "A Hybrid 727 Authentication Mode for IKE", draft-ietf-ipsec- 728 isakmp-hybrid-auth-02 730 Internet Draft Dec-99 732 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 733 (IKE)", RFC2409 735 [IKEv2] D. Harkins, D. Carrel, "The Internet Key Exchange 736 (IKE)", draft-ietf-ipsec-ike-00.txt 738 [IKECFG] R. Pereira, "The ISAKMP Configuration Method", 739 draft-ietf-ipsec-isakmp-cfg-05 741 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, 742 "Remote Authentication Dial In User Service 743 (RADIUS)", RFC2138 745 [OTP] N. Haller, C. Metz, "A One-Time Password System", 746 RFC1938 748 [SKEY] N. Haller, "The S/KEY One-Time Password System", 749 RFC1760 751 [TACACS] C. Finseth, "An Access Control Protocol, Sometimes 752 Called TACACS", RFC1492 754 [TACACS+] D. Carrel, L. Grant, "The TACACS+ Protocol Version 755 1.77", draft-grant-tacacs-01.txt 757 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 759 10 Acknowledgements 761 The authors would like to thank Tamir Zegmen, Moshe Litven, Dan 762 Harkins and all those from the IPsec community who have helped 763 improve the XAUTH protocol either. We would also like to thank Tim 764 Jenkins, Ajai Puri, Laurie Shields, Andrew Krywaniuk, Gabriela 765 Dinescu, Paul Kierstead and Scott Fanning for their continued 766 support, and many sanity checks along the way. 768 Internet Draft Dec-99 770 11 Authors' Addresses 772 Roy Pereira 773 774 Cisco Systems 775 +1 (613) 788-7207 777 Stephane Beaulieu 778 779 TimeStep Corporation 780 +1 (613) 599-3610 x 4709 782 The IPSRA working group can be contacted via the IPSec working 783 group's mailing list (ietf-ipsra@vpnc.org) or through its chairs: 785 Roy Pereira 786 royp@cisco.com 787 Cisco Systems 789 Sara Bitan 790 sarab@radguard.com 791 Radguard 793 11 Expiration 795 This draft expires May, 2000 797 12 Full Copyright Statement 799 Copyright (C) The Internet Society (1998). All Rights Reserved. 801 This document and translations of it may be copied and furnished to 802 others, and derivative works that comment on or otherwise explain 803 it or assist in its implementation may be prepared, copied, 804 published and distributed, in whole or in part, without restriction 805 of any kind, provided that the above copyright notice and this 806 paragraph are included on all such copies and derivative works. 807 However, this document itself may not be modified in any way, such 808 as by removing the copyright notice or references to the Internet 809 Society or other Internet organizations, except as needed for the 810 purpose of developing Internet standards in which case the 811 procedures for copyrights defined in the Internet Standards process 812 must be followed, or as required to translate it into languages 813 other than English. 815 The limited permissions granted above are perpetual and will not be 816 revoked by the Internet Society or its successors or assigns. 818 Internet Draft Dec-99 820 This document and the information contained herein is provided on 821 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 822 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 823 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 824 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 825 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 Internet Draft Dec-99 829 Appendix A 831 This appendix gives more useful examples of Extended 832 Authentication. 834 Secure ID Next PIN mode 835 ======================= 837 Ipsec Client Ipsec Gateway 838 ------------ ------------- 839 <-- REQUEST(Username = '', Password = '') 840 REPLY(Username = 'joe', Password = '1637364856') --> 841 <-- REQUEST(Password = '', XAUTH_MESSAGE = 'The system has 842 assigned you a new PIN, do you wish to see it now?') 843 REPLY(Password = 'y') --> 844 <-- REQUEST(Password = '', XAUTH_MESSAGE 845 = 'Your new pin is 1234' 846 REPLY(Password = '1234764456') --> 847 <-- SET(XAUTH_STATUS = OK) 848 ACK(XAUTH_STATUS) --> 850 RADIUS Chap Challenge 851 ===================== 853 Ipsec Client Ipsec Gateway 854 ------------ ------------- 855 <-- REQUEST(TYPE = RADIUS-CHAP, Username = '', Password = '', 856 Challenge = 0x01020304050607080910111213141516) 857 REPLY(TYPE = RADIUS-CHAP, Username = 'joe', Password = 858 '0xaa11121314151617181920212223242526') --> 859 <-- SET(XAUTH_STATUS = OK) 860 ACK(XAUTH_STATUS) --> 862 where the Challenge in the REQUEST is the random number generated 863 by the edge device, and the Password in the reply contains the ID 864 used to calculate the hash 'aa' concatenated with the hash of the 865 (ID+challenge+secret)