1 2 3 4 5 S. Beaulieu 6Internet Draft R. Pereira 7Document: <draft-beaulieu-ike-xauth-02.txt> Cisco Systems 8Expires April 2002 9 October 2001 10 11 12 Extended Authentication within IKE (XAUTH) 13 14 15Status of this Memo 16 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 341. Abstract 35 36 [IKE] allows a device to set up a secure session by using a 37 bidirectional authentication method using either pre-shared keys or 38 digital certificates. However [IKE] does not provide a method to 39 leverage legacy authentication methods which are widely deployed 40 today. 41 42 This document describes a method for using existing unidirectional 43 authentication mechanisms such as RADIUS, SecurID, and OTP within 44 IPsec's ISAKMP protocol. The purpose of this draft is not to 45 replace or enhance the existing authentication mechanisms described 46 in [IKE], but rather to allow them to be extended using legacy 47 authentication mechanisms. 48 49 This protocol is designed in such a way that extended authentication 50 may be accomplished using any mode of operation for phase 1 (i.e. 51 Main Mode or Aggressive Mode) as well as any authentication method 52 supported by [IKE]. This protocol may also be easily extended to 53 support new modes or authentication methods. This protocol does 54 however require that the phase 1 authentication method be fully 55 secure. 56 57 58 59 60Beaulieu, Pereira 1 61 62 Extended Authentication with ISAKMP/Oakley October 2001 63 64 65 The authors currently intend this document to be published as an 66 Informational RFC, not a standards-track document, so that the many 67 IPsec implementations that have implemented to earlier drafts of 68 this protocol can have a single stable reference. 69 70 Comments regarding this draft should be sent to ietf-xauth@vpnc.org 71 or to the authors. 72 73 742. Conventions used in this document 75 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 78 this document are to be interpreted as described in RFC-2119 [2]. 79 80 813. Introduction 82 83 The following technique allows IPsec's ISAKMP/Oakley [IKE] protocol 84 to support extended authentication mechanisms like two-factor 85 authentication, challenge/response and other remote access 86 unidirectional authentication methods. 87 88 These authentication mechanisms have a large deployment in remote 89 access applications and many IT departments have requirements for 90 these unidirectional authentication mechanisms. 91 92 This draft defines packet formats for a protocol which allows you to 93 carry legacy authentication information from one peer to another. 94 It does so by extending the [IKECFG] protocol. This protocol 95 requires a sufficient level of security from the phase 1 SA 96 authentication. 97 98 This protocol may be used in conjunction with a multitude of 99 combinations of modes (i.e. Main Mode, Aggressive Mode, etc) and 100 authentication methods (i.e. Pre-Shared keys, RSA Signatures, DSS 101 Signatures, etc). This protocol has also been designed to work 102 with any new modes and authentication methods. 103 104 This draft also specifies how to accomplish legacy authentication 105 when used with the existing modes and authentication methods defined 106 in IKE (the assumption here being that they offer "sufficient" level 107 of security to protect the XAUTH exchange). This is accomplished by 108 extending the [IKE] protocol. 109 110 111 The document has been published as informational as the IPSRA 112 working group will not accept any protocol which extends ISAKMP or 113 IKE. Furthermore, the IPsec working group refuses to accept any 114 protocols that deal with remote access. 115 116 At the time of the writing of this draft, the IPSRA working group 117 has still not defined a protocol to solve the issue of legacy 118 119Beaulieu, Pereira 2 120 121 Extended Authentication with ISAKMP/Oakley October 2001 122 123 124 authentication. XAUTH has been in existance for several years, and 125 has successfully proven interoperability. Several vendors have 126 implemented and deployed the protocol. Several vendors wish to 127 implement the protocol but have had problems finding the protocol 128 specification. For this reason, the draft is being republished as 129 informational to give new vendors an opportunity to interoperate 130 with the many existing vendors who implement this protocol today. 131 132 133 1343.1. Changes since last revision. 135 136 The last revision of this document was published as "draft-beaulieu- 137 ike-xauth-01.txt" 138 139 o clarified text regarding CHALLENGE attribute 140 o clarified text regarding NEXT-PIN attribute 141 142 1433.2. Extended Authentication 144 145 Two-factor authentication and challenge/response schemes like SDI's 146 SecurID and RADIUS are forms of authentication that allow a gateway, 147 firewall, or network access server to offload the user 148 administration and authentication to a central management server. 149 IPsec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 150 shared-secret, and Kerberos as authentication methods, but since the 151 authentication methods described within this document are only 152 unidirectional authentication methods (client to a 153 gateway/firewall), they cannot be used by themselves, but must be 154 used in conjunction with the other standard ISAKMP authentication 155 methods. 156 157 The technique described within this document utilizes ISAKMP to 158 transfer the user's authentication information (name, password) to 159 the gateway/firewall (edge device) in a secured ISAKMP message. The 160 edge device would then use the appropriate protocol (RADIUS, 161 SecurID, OTP) to authenticate the user. This allows the 162 authentication server to be within the private network that the edge 163 device is protecting. 164 165 1663.3. Reader Prerequisites 167 168 It is assumed that the reader is familiar with the terms and 169 concepts described in the "Security Architecture for the Internet 170 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 171 documents. 172 173 Readers are advised to be familiar with both [IKE] and [ISAKMP] as 174 well as [IKECFG] since this document is an extension to that 175 document. 176 177 178 179Beaulieu, Pereira 3 180 181 Extended Authentication with ISAKMP/Oakley October 2001 182 183 1844. Vendor ID 185 186 XAUTH currently uses attribute numbers from the private ranges of 187 both [IKE] and [IKECFG]. In order to ensure interoperability with 188 future and past implementations of XAUTH a Vendor ID has been added. 189 The Vendor ID payload is sent during the phase 1 exchange as per 190 [ISAKMP]. The vendor id payload SHOULD be authenticated whenever 191 possible. Two IKE implementations which support the [KIV] document 192 will be capable of doing this. The Vendor ID for this revision of 193 XAUTH is the following 8 bytes. 194 195 Vendor ID = 0x09002689DFD6B712 196 197 If an implementation receives the aforementioned Vendor ID, it can 198 assume that the peer also has implemented this protocol and 199 therefore is a "mutually consenting party". 200 201 If this document ever advances to the standard-track, then new 202 numbers will be assigned by IANA from the appropriate number spaces 203 of [IKE] and [IKECFG], thus eliminating the need for a Vendor ID 204 payload. 205 206 207 208 2095. Extended Authentication Method 210 211 This specification allows for extended authentication by allowing an 212 edge device to request extended authentication from an IPsec host 213 (end-node), thus forcing the host to respond with its extended 214 authentication credentials. The edge device will then respond with 215 a failed or passed message. 216 217 When the edge device requests extended authentication, it will 218 specify the type of extra authentication and any parameters required 219 for it. These parameters MAY be the attributes that it requires for 220 authentication and they MAY be information required for the IPsec 221 host's reply (e.g. challenge string). 222 223 The Extended Authentication transaction is terminated either when 224 the edge device starts a SET/ACK exchange which includes an 225 XAUTH_STATUS attribute or when the remote device sends a 226 XAUTH_STATUS attribute in a REPLY message. Please note that a 227 remote device can not set XAUTH_STATUS to anything but FAIL. 228 229 The edge device MAY request multiple different authentication 230 transactions within one Extended Authentication transaction. This 231 is done by having multiple REQUEST/REPLY pairs, initiated by the 232 edge device, before the transaction is terminated as described 233 above. Each REQUEST/REPLY pair MAY have a different value for 234 XAUTH_TYPE. 235 236 237 238Beaulieu, Pereira 4 239 240 Extended Authentication with ISAKMP/Oakley October 2001 241 242 243 As with CHAP [CHAP], this protocol can also be used to periodically 244 authenticate the user during the lifetime of a security association. 245 246 If the IPsec host does not have support for the authentication 247 method requested by the edge device, then it would send back a REPLY 248 with the XAUTH_STATUS attribute set to FAIL, thus failing the 249 authentication but completing the transaction. 250 251 252 The Extended Authentication mechanism does not effect the nature of 253 the phase 1 authentication mechanism in any way. Both peers MUST 254 authenticate each other via the authentication methods described in 255 [IKE] or some other authentication method in the ISAKMP framework. 256 There are Security Considerations involved in at least one of the 257 authentication methods in [IKE] and this is described in "Security 258 Considerations" below. 259 260 This method provides unidirectional authentication only, meaning 261 that only one device is authenticated using both IKE authentication 262 methods and Extended Authentication. 263 264 Here are some types of extended authentication that this 265 specification supports: 266 267 268 2695.1 Simple Authentication 270 271 Where a user name and password are required for authentication. 272 273 IPsec Host Edge Device 274 -------------- ----------------- 275 <-- REQUEST(NAME="" PASSWORD="") 276 REPLY(NAME="joe" PASSWORD="foobar") --> 277 <-- SET(STATUS=OK) 278 ACK(STATUS) --> 279 280 Some authentication mechanisms hide the user password by some type 281 of encryption mechanism. 282 283 284 IPsec Host Edge Device 285 -------------- ----------------- 286 <-- REQUEST(TYPE=RADIUS-CHAP 287 CHALLENGE="123456" NAME="" PASSWORD="") 288 REPLY(TYPE=RADIUS-CHAP NAME="joe" PASSWORD="E4901AB7") --> 289 <-- SET(STATUS=OK) 290 ACK(STATUS) --> 291 292 NOTE: This is a conceptual example of RADIUS-CHAP, for a more 293 detailed example, see Appendix A. 294 295 2965.2 Challenge/Response 297 298 299Beaulieu, Pereira 5 300 301 Extended Authentication with ISAKMP/Oakley October 2001 302 303 304 305 Where a challenge from the edge device must be incorporated with the 306 reply. This makes each reply different. 307 308 IPsec Host Edge Device 309 -------------- ----------------- 310 <-- REQUEST(NAME="" PASSWORD="") 311 REPLY(NAME="joe" PASSWORD="foobar") --> 312 <-- REQUEST(MESSAGE="Enter your password followed by 313 your pin number" NAME="" PASSWORD="") 314 REPLY(NAME="joe" PASSWORD="foobar0985124") --> 315 <-- SET(STATUS=OK) 316 ACK(STATUS) --> 317 318 If, however, the edge device knows that a challenge will be required 319 it may skip the first exchange as follows: 320 321 IPsec Host Edge Device 322 -------------- ----------------- 323 <-- REQUEST(MESSAGE="Enter your password followed by 324 your pin number" NAME="" PASSWORD="") 325 REPLY(NAME="joe" PASSWORD="foobar0985124") --> 326 <-- SET(STATUS=OK) 327 ACK(STATUS) --> 328 3295.3 Two-Factor Authentication 330 331 This authentication method combines something the user knows (their 332 password) and something that the user has (a token card). 333 334 IPsec Host Edge Device 335 -------------- ----------------- 336 <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") 337 REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="3412") --> 338 <-- SET(STATUS=OK) 339 ACK(STATUS) --> 340 341 Some mechanisms allow for another optional request of the passcode. 342 343 IPsec Host Edge Device 344 -------------- ----------------- 345 <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") 346 REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="323415") --> 347 <-- REQUEST(NAME="" PASSWORD="" PASSCODE="") 348 REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="513212") --> 349 <-- SET(STATUS=OK) 350 ACK(STATUS) --> 3515.4 One-Time-Password 352 353 Similar to the Challenge/Response method, this method allows 354 authentication that is secure against passive attacks based on 355 replaying captured passwords. 356 357 358 359Beaulieu, Pereira 6 360 361 Extended Authentication with ISAKMP/Oakley October 2001 362 363 364 IPsec Host Edge Device 365 -------------- ----------------- 366 <-- REQUEST(TYPE=OTP CHALLENGE, NAME="") 367 REPLY(TYPE=OTP_CHALLENGE, NAME="joe")--> 368 <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" 369 NAME="" PASSWORD="") 370 REPLY(TYPE=OTP NAME="joe" PASSWORD="5bf0 75d9 959d 036f") --> 371 <-- SET(STATUS=OK) 372 ACK(STATUS) --> 373 374 3755.5 User Previously Authenticated 376 377 Some situations may occur where the edge device has already 378 authenticated the host and no new authentication is required. This 379 may happen when either the host or the edge device must rekey an 380 existing phase 1 SA. It is important that this method not be used, 381 unless the implementation can be sure that the current phase 1 SA 382 was created with the same peer as the initial phase 1 SA, which was 383 previously authenticated using XAUTH. There is currently no way 384 defined to ensure that two separate phase 1 SAs actually belong to 385 the same peer. One method suggested is to use the ID from the phase 386 1 negotiation (available in Main Mode and Aggressive Mode) but only 387 if the ID is unique to the user and cannot not be forged. This 388 concept is herein referred to as "ID-Checking". 389 390 Implementation hint: 391 392 o In order to accomplish ID-Checking for Phase 1 Authenticated With 393 a Pre-Shared Key (as defined in [IKE]), the pre-shared key lookup 394 must be based on the phase 1 ID. Please note that this method only 395 currently works for Aggressive Mode, and may work with modes defined 396 in the future. A static IP address could also be used for shared 397 secret lookup, however, the binding of the user to XAUTH session 398 would have to use the IP address instead of the ID. 399 400 401 o In order to accomplish ID-Checking for IKE Phase 1 Authenticated 402 With Signatures (as defined in [IKE]), the implementation must 403 ensure that the ID provided in the phase 1 exchange matches the ID 404 in the peer's certificate which must be signed by a trusted third 405 party. 406 407 408 409 In the situation where the peer does not require additional 410 authentication, the following method is used. 411 412 IPsec Host Edge Device 413 ------------- ---------------- 414 <-- SET(STATUS=OK) 415 ACK(STATUS) --> 416 417 418Beaulieu, Pereira 7 419 420 Extended Authentication with ISAKMP/Oakley October 2001 421 422 4235.6 Other Useful Examples 424 425 More useful examples are found in Appendix A. 426 427 4286 Extensions to ISAKMP-Config 429 430 This protocol uses the mechanisms described in ISAKMP-Config 431 [IKECFG] to accomplish its authentication transaction. This 432 protocol uses Configuration Attributes from the private range of 433 Isakmp-Config [IKECFG]. To ensure interoperability with past and 434 future versions of Extended Authentication, a Vendor ID is provided 435 in section 2. 436 437 All ISAKMP-Config messages in an extended authentication transaction 438 MUST contain the same ISAKMP-Config transaction identifier. The 439 Message ID in the ISAKMP header follows the rules defined by the 440 ISAKMP-Config protocol. 441 442 This protocol can therefore be used in conjunction with any existing 443 basic ISAKMP authentication method as defined in [IKE]. 444 445 This authentication MUST be used after a phase 1 exchange has 446 completed and before any other exchange with the exception of Info 447 mode exchanges. If the extended authentication fails, then the phase 448 1 SA MUST be immediately deleted. The edge device MAY choose to 449 retry an extended authentication request if the user failed to be 450 authenticated, but must do so in the same ISAKMP-Config transaction, 451 and MUST NOT send the SET message until the user is authenticated, 452 or until the edge device wishes to stop retrying and fail the user. 453 454 Extended Authentication MAY be initiated by the edge device at any 455 time after the initial authentication exchange. For example, RADIUS 456 servers may specify that a user only be authenticated for a certain 457 time period. Once that time period has elapsed (minus a possible 458 jitter), the edge device may request a new Extended Authentication 459 exchange. If the Extended Authentication exchange fails, the edge 460 device MUST tear down all phase 1 and phase 2 SAs associated with 461 the user. 462 463 The following are extensions to the ISAKMP-Config [IKECFG] 464 specification to support Extended Authentication. 465 4666.1 Message Types 467 468 Type Value 469 -------------------------- ----------------------------- 470 ISAKMP-CFG-REQUEST ( as defined in [IKECFG] ) 471 ISAKMP-CFG-REPLY ( as defined in [IKECFG] ) 472 ISAKMP-CFG-SET ( as defined in [IKECFG] ) 473 ISAKMP-CFG-ACK ( as defined in [IKECFG] ) 474 475 476 477Beaulieu, Pereira 8 478 479 Extended Authentication with ISAKMP/Oakley October 2001 480 481 482 ISAKMP-CFG-REQUEST - This message is sent from an edge device to an 483 IPsec host trying to request extended authentication. Attributes 484 that it requires sent back in the reply MUST be included with a 485 length of zero (0). Attributes required for the authentication 486 reply, such as a challenge string MUST be included with the proper 487 values filled in. 488 489 ISAKMP-CFG-REPLY - This message MUST contain the filled in 490 authentication attributes that were requested by the edge device or 491 if the proper authentication attributes can not be retrieved, then 492 this message MUST contain the XAUTH-STATUS attribute with a value of 493 FAIL. 494 495 ISAKMP-CFG-SET - This message is sent from an edge device and is 496 only used, within the scope of this document, to state the success 497 of the authentication. This message MUST only include the success 498 of failure of the authentication and MAY contain some clarification 499 text. 500 501 ISAKMP-CFG-ACK - This message is sent from the IPsec host 502 acknowledging receipt of the authentication result. Its attributes 503 are not relevant and MAY be skipped entirely, thus no attributes 504 SHOULD be included. This last message in the authentication 505 transaction is used solely as an acknowledgement of the previous 506 message and to eliminate problems with unacknowledged messages over 507 UDP. 508 5096.2 Attributes 510 511 Attribute Value Type 512 --------------------- ------ --------------------- 513 XAUTH-TYPE 16520 Basic 514 XAUTH-USER-NAME 16521 Variable ASCII string 515 XAUTH-USER-PASSWORD 16522 Variable ASCII string 516 XAUTH-PASSCODE 16523 Variable ASCII string 517 XAUTH-MESSAGE 16524 Variable ASCII string 518 XAUTH-CHALLENGE 16525 Variable ASCII string 519 XAUTH-DOMAIN 16526 Variable ASCII string 520 XAUTH-STATUS 16527 Basic 521 XAUTH-NEXT-PIN 16528 Variable ASCII string 522 XAUTH-ANSWER 16529 Variable ASCII string 523 524 NOTE: Variable ASCII strings need not be NULL-terminated, as the 525 length field in the attribute header is sufficient to properly 526 format the strings. 527 528 XAUTH-TYPE - The type of extended authentication requested whose 529 values are described in the next section. This is an optional 530 attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY messages. 531 If the XAUTH-TYPE is not present, then it is assumed to be Generic. 532 The XAUTH-TYPE in a REPLY MUST be identical to the XAUTH-TYPE in the 533 REQUEST. If the XAUTH-TYPE was not present in the REQUEST, then it 534 MUST NOT be present in the REPLY. However, an XAUTH transaction MAY 535 536Beaulieu, Pereira 9 537 538 Extended Authentication with ISAKMP/Oakley October 2001 539 540 541 have multiple REQUEST/REPLY pairs with different XAUTH-TYPE values 542 in each pair. 543 544 XAUTH-USER-NAME - The user name MAY be any unique identifier of the 545 user such as a login name, an email address, or a X.500 546 Distinguished Name. 547 548 XAUTH-USER-PASSWORD - The user's password. 549 550 XAUTH-PASSCODE - A token card's passcode. 551 552 XAUTH-MESSAGE - A textual message from an edge device to an IPsec 553 host. The message may contain a textual challenge or instruction. 554 An example of this would be "Enter your password followed by your 555 pin number". The message may also contain a reason why 556 authentication failed or succeeded. This message SHOULD be 557 displayed to the user. 558 559 XAUTH-CHALLENGE - A challenge string sent from the edge device to 560 the IPsec host for it to include in its calculation of a password. 561 This attribute SHOULD only be sent in an ISAKMP-CFG-REQUEST message. 562 Typically, the XAUTH-TYPE attribute dictates how the receiving 563 device should handle the challenge. For example, RADIUS-CHAP uses 564 the challenge to hide the password. The XAUTH-CHALLENGE attribute 565 MUST NOT be used when XAUTH-TYPE is set to generic. 566 567 XAUTH-DOMAIN - The domain to be authenticated in. This value will 568 have different meaning depending on the authentication type. 569 570 XAUTH-STATUS - A variable that is used to denote authentication 571 success (OK=1) or failure (FAIL=0). This attribute MUST be sent in 572 the ISAKMP-CFG-SET message, in which case it may be set to either OK 573 or FAIL, and MAY be sent in a REPLY message by a remote peer, in 574 which case it MUST be set to FAIL. 575 576 XAUTH-NEXT-PIN - A variable which is used when the edge device is 577 requesting that the user choose a new pin number. This attribute 578 MUST NOT be used in conjunction with any attributes other than 579 XAUTH-MESSAGE and / or XAUTH-TYPE. 580 581 XAUTH-ANSWER - A variable length ASCII string used to send input to 582 the edge device. An edge device MAY include this attribute in a 583 REQUEST message in order to prompt an answer from the user, though 584 it MUST be accompanied by an XAUTH-MESSAGE attribute. This attribute 585 MUST NOT be used in conjunction with any attributes other than 586 XAUTH-TYPE or XAUTH-MESSAGE. 587 5886.3 Authentication Types 589 590 Value Authentication Required 591 ----- --------------------------------- 592 593 594 595 596Beaulieu, Pereira 10 597 598 Extended Authentication with ISAKMP/Oakley October 2001 599 600 601 0 Generic 602 1 RADIUS-CHAP 603 2 OTP 604 3 S/KEY 605 4-32767 Reserved for future use 606 32768-65535 Reserved for private use 607 608 Generic - A catch-all type that allows for future extensibility and 609 a generic mechanism to request authentication information. This 610 method allows for any type of extended authentication which does not 611 require specific processing, and should be used whenever possible. 612 This is the default setting if no XAUTH_TYPE is present. 613 614 RADIUS-CHAP - RADIUS-CHAP is one method of authentication defined in 615 [RADIUS] which uses a challenge to hide the password. In order to 616 use the CHAP functionality defined in [RADIUS], the XAUTH_TYPE MUST 617 be set to RADIUS-CHAP. For all other methods defined in [RADIUS] 618 (i.e. PAP), the XAUTH_TYPE MUST be set to Generic. 619 620 OTP - One-Time-Passwords as defined in [OTP] uses a challenge string 621 to request a certain generated password. The request SHOULD contain 622 a user name, password and a challenge string while the reply MUST 623 contain the user name and the generated password. The challenge 624 string is formatted as defined in [OTPEXT]. 625 S/KEY - This one-time-password scheme defined in [SKEY] was the 626 precursor to OTP, thus the same rules applies. 627 628 6297. XAUTH Notification 630 631 It is important the edge device be able to notify the remote device 632 of its intent to prompt for extended authentication. If such a 633 mechanism were not present, the remote device would send a Quick 634 Mode message, or a Mode-Cfg message before authentication was 635 complete, and the state machines would get pretty complicated. 636 637 We present here two methods of accomplishing this. The first is the 638 simplest, and most intuitive. However it is not possible to achieve 639 this within the [IKE] protocol as it stands today, and is therefore 640 not recommended. It has been added to this document for 641 completeness, and may be used in future versions of this document. 642 6437.1 Notification payloads within a phase 1 exchange 644 645 The following method is used to notify the remote device that an 646 XAUTH exchange will follow the phase 1 exchange. Once the edge 647 device does a policy lookup for the peer, the edge device appends a 648 notify payload to any phase 1 exchange packet, indicating that an 649 XAUTH exchange will follow. Note, that this notify payload is 650 unauthenticated unless both devices support the mechanisms described 651 in [KIV]. Therefore, implementations MUST NOT use this method 652 unless they are also using the mechanisms described in [KIV]. 653 654 655Beaulieu, Pereira 11 656 657 Extended Authentication with ISAKMP/Oakley October 2001 658 659 660 Once again, this method is not part of the XAUTH protocol in its 661 present form. It has only been added here for completeness, and may 662 be used in future versions of this document. 663 664 No payload definitions, assigned numbers, or vendor ID payloads will 665 be provided for this method, as it is currently not part of the 666 XAUTH protocol. These may be defined in the future if enough 667 interest is shown, and if [KIV] becomes a standardized within the 668 IPsec working group. 669 6707.2 Notification via Authentication Method Types 671 672 The following method is used to negotiate the use of XAUTH via the 673 SA payload. New authentication methods are defined which allow the 674 edge device to choose an authentication method which mandates XAUTH. 675 This allows the edge device to notify the remote device that an 676 XAUTH exchange will follow the phase 1 exchange. Edge devices which 677 conform to this document MUST support this method. 678 679 680 The following values relate to the ISAKMP authentication method 681 attribute used in proposals. They optionally allow an XAUTH 682 implementation to propose use of extended authentication after the 683 initial phase 1 authentication. Values are taken from the private 684 use range defined in [IKE] and should be used among mutually 685 consenting parties. To ensure interoperability and avoid 686 collisions, a Vendor ID is provided in the "Vendor ID" section of 687 this document. 688 689 Method Value 690 ------------------------------ ----- 691 XAUTHInitPreShared 65001 692 XAUTHRespPreShared 65002 693 XAUTHInitDSS 65003 694 XAUTHRespDSS 65004 695 XAUTHInitRSA 65005 696 XAUTHRespRSA 65006 697 XAUTHInitRSAEncryption 65007 698 XAUTHRespRSAEncryption 65008 699 XAUTHInitRSARevisedEncryption 65009 700 XAUTHRespRSARevisedEncryption 65010 701 702 703 An Extended Authentication proposal has two characteristics. 704 705 The first is the direction of the authentication. Each type 706 identifies whether the Initiator or the Responder is the device 707 which should be authenticated using XAUTH. For example 708 XAUTHInitPreShared is a type which demands that the Initiator be 709 authenticated. 710 711 Note that an edge device would typically initiate with one of the 712 following: 713 714Beaulieu, Pereira 12 715 716 Extended Authentication with ISAKMP/Oakley October 2001 717 718 719 o XAUTHRespPreShared 720 o XAUTHRespDSS 721 o XAUTHRespRSA 722 o XAUTHRespRSAEncryption 723 o XAUTHRespRSARevisedEncryption 724 725 and would typically only accept proposals with the following 726 authentication methods: 727 o XAUTHInitPreShared 728 o XAUTHInitDSS 729 o XAUTHInitRSA 730 o XAUTHInitRSAEncryption 731 o XAUTHInitRSARevisedEncryption 732 733 The second characteristic is the IKE Authentication method to be 734 used. The following table illustrates which keywords in the methods 735 described above relate to which Authentication Methods described in 736 [IKE] Appendix A. 737 738 739 740 "PreShared" -> pre-shared key 741 "DSS" -> DSS signatures 742 "RSA" -> RSA signatures 743 "RSAEncryption" -> Encryption with RSA 744 "RSARevisedEncryption" -> Revised encryption with RSA 745 746 7478. Other Scenarios for Extended Authentication 748 749 Although this document described a scenario where an IPsec host (eg. 750 mobile user) was being authenticated by an edge device (eg. 751 firewall/gateway), the methods described can also be used for edge 752 device to edge device authentication as well as IPsec host to IPsec 753 host authentication. 754 7559. Extensibility 756 757 Although this protocol was initially developed for the corporate 758 "Road Warrior" with a dynamic IP address to connect to a corporate 759 Net, there may be certain applications where static IP addresses are 760 used by the "Road Warrior" or where this protocol is used in a non 761 remote-user environment where the IP address is static. There are 762 Security Considerations for certain applications of this protocol in 763 certain deployment scenarios. Please consult the "Security 764 Considerations" section below for more detail. 765 766 [IKE] defines many different ways to authenticate a user and 767 generate keying material. There are two basic phase 1 modes 768 defined: Main Mode and Aggressive Mode. There are also at least 5 769 different authentication schemes which can be used with each mode. 770 771 772 773 774Beaulieu, Pereira 13 775 776 Extended Authentication with ISAKMP/Oakley October 2001 777 778 779 New authentication schemes are being developed and surely more will 780 be standardized in the future. Similarly new phase 1 modes are 781 being proposed to address weaknesses or missing functionality in 782 Main Mode and/or Aggressive mode. 783 784 It is for this reason that XAUTH was designed to be fully 785 extensible. Since XAUTH extends the phase 1 authentication provided 786 by [IKE], it is an important design goal that a legacy user 787 authentication scheme in IPsec be able to use the strengths of 788 current and future authentication and key generation schemes. 789 790 XAUTH accomplishes this by working with all modes which allow the 791 negotiation of a phase 1 authentication method in ISAKMP. Any new 792 authentication methods defined in the future which are not addressed 793 by this document need simply to take values from the "consenting 794 parties" ranges of [IKE]. Such an example would be the introduction 795 of Encryption with El-Gamal and Revised Encryption with El-Gamal, 796 and [HYBRID]. Furthermore, any new modes defined such as Base Mode, 797 will automatically be able to use the functionality of XAUTH as no 798 new numbers are needed. 799 800 Finally, any new or forgotten Legacy User Authentication Schemes 801 which are not part of XAUTH can be easily incorporated by taking 802 numbers from the "consenting parties" ranges of XAUTH, or by 803 requesting reserved numbers from IANA. 804 805 806 80710. Security Considerations 808 809 Care should be taken when sending sensitive information over public 810 networks such as the Internet. A user's password should never be 811 sent in the clear and when sent encrypted, the destination MUST have 812 been previously authenticated. The use of ISAKMP-Config [IKECFG] 813 addresses these issues. 814 815 The protocol described in this memo strictly extends the 816 authentication methods described in [IKE]. It does not in any way 817 affect the authenticated nature of the phase 1 security association. 818 In fact, this protocol heavily relies on the authenticated nature of 819 the phase 1 SA. Without complete phase 1 authentication, this 820 protocol does not provide protection against man-in-the-middle 821 attacks. Therefore it MUST NOT be used without normal phase 1 822 authentication. This protocol was designed to be extensible, and 823 can be used in many possible combinations of phase 1 Modes and 824 authentication methods. However, certain combinations of scenarios 825 could lead to weaker than desired security, and are therefore 826 discouraged. 827 828 When using XAUTH with Pre-Shared keys, where the peer's IP address 829 is dynamic, Main Mode SHOULD NOT be used, and is STRONGLY 830 DISCOURAGED. In this particular scenario, the phase 1 authentication 831 becomes suspect as the administrator has little choice but to use 832 833Beaulieu, Pereira 14 834 835 Extended Authentication with ISAKMP/Oakley October 2001 836 837 838 one single Shared-Key for all users, and group-shared keys are 839 susceptible to "social engineering attacks". 840 841 However, the choice of implementation of this functionality is left 842 up to the implementers of this protocol. There may be some 843 applications where this functionality is desired. Some examples 844 are: proof of concept deployments and small deployments where the 845 proper management of a group shared-key is less difficult. 846 847 If at some point restrictions are introduced in one of the IPsec 848 Standard RFC documents which prohibit the use of group pre-shared 849 keys, then this protocol will, by default, conform, and these 850 Security Considerations will no longer be of concern. 851 852 853 854 85511. References 856 857 858 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 859 BCP 9, RFC 2026, October 1996. 860 861 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 862 Levels", BCP 14, RFC 2119, March 1997 863 864 865 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication Protocol 866 (CHAP)", RFC1994 867 868 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 869 draft-calhoun-diameter-02.txt 870 871 [HYBRID] M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication 872 Mode for IKE", draft-ietf-ipsec-isakmp-hybrid-auth-05 873 874 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 875 RFC2409 876 877 [IKECFG] D. Dukes, R. Pereira, "The ISAKMP Configuration Method", 878 draft-dukes-ike-mode-cfg-01.txt 879 880 [KIV] Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication HASHs", 881 "draft-ietf-ipsec-ike-hash-revised-01.txt", work in progress. 882 883 [OTP] N. Haller, C. Metz, P. Nesser, M. Straw, "A One-Time Password 884 System", RFC2289 885 886 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 887 888 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 889 Authentication Dial In User Service (RADIUS)", RFC2138 890 891 892Beaulieu, Pereira 15 893 894 Extended Authentication with ISAKMP/Oakley October 2001 895 896 897 [SKEY] N. Haller, "The S/KEY One-Time Password System", RFC1760 898 899 [TACACS] C. Finseth, "An Access Control Protocol, Sometimes Called 900 TACACS", RFC1492 901 902 [TACACS+] D. Carrel, L. Grant, "The TACACS+ Protocol Version 1.77", 903 draft-grant-tacacs-01.txt 904 905 90612. 907 Acknowledgments 908 909 The authors would like to thank Tamir Zegmen, Moshe Litvin, Dan 910 Harkins and all those from the IPsec community who have helped 911 improve the XAUTH protocol. We would also like to thank Tim 912 Jenkins, Ajai Puri, Laurie Shields, Andrew Krywaniuk, Gabriela 913 Dinescu, Paul Kierstead and Scott Fanning for their continued 914 support, and many sanity checks along the way. 915 916 91713. Author's Addresses 918 919 Stephane Beaulieu 920 <stephane@cisco.com> 921 Cisco Systems Co. 922 +1 (613) 721-3678 923 924 Roy Pereira 925 <royp@cisco.com> 926 Cisco Systems 927 +1 (408) 526-6793 928 929 93014. Expiration 931 932 This draft expires April, 2002 933 934 935Full Copyright Statement 936 937 "Copyright (C) The Internet Society (date). All Rights Reserved. 938 This document and translations of it may be copied and furnished to 939 others, and derivative works that comment on or otherwise explain it 940 or assist in its implmentation may be prepared, copied, published 941 and distributed, in whole or in part, without restriction of any 942 kind, provided that the above copyright notice and this paragraph 943 are included on all such copies and derivative works. However, this 944 document itself may not be modified in any way, such as by removing 945 the copyright notice or references to the Internet Society or other 946 Internet organizations, except as needed for the purpose of 947 developing Internet standards in which case the procedures for 948 copyrights defined in the Internet Standards process must be 949 followed, or as required to translate it into 950 951 952 953Beaulieu, Pereira 16 954 955 Extended Authentication with ISAKMP/Oakley October 2001 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012Beaulieu, Pereira 17 1013 1014 Extended Authentication with ISAKMP/Oakley October 2001 1015 1016 1017Appendix A 1018 1019 1020 This appendix gives more useful examples of Extended Authentication. 1021 1022 SDI through RADIUS 1023 ================== 1024 1025 The following 3 examples show examples of SDI running through 1026 RADIUS. Since the edge device does not necessarily know that we are 1027 indeed doing SDI, the edge device will typically send everything in 1028 terms of Username and Password. This of course results in the user 1029 being prompted with a password dialog when it isn't really a 1030 password which is required. This tends to be a little confusing, 1031 but it is really a limitation of RADIUS. 1032 1033 NOTE: The edge device may choose to try and detect these situations 1034 and send better suited XAUTH attributes (such as XAUTH ANSWER or 1035 XAUTH NEXT PIN). The Client is typically protocol agnostic and will 1036 prompt the user for whatever attributes the edge device requests. 1037 1038 1039 1040 Example A-1: 1041 ============ 1042 Secure ID Next PIN mode via RADIUS (Scenario 1 - SDI generated next 1043 pin) 1044 1045 IPsec Client IPsec Gateway 1046 ------------ ------------- 1047 <-- REQUEST(Username = '', Password = '') 1048 REPLY(Username = 'joe', Password = '1637364856') --> 1049 <-- REQUEST(Username = '', Password = '', 1050 XAUTH_MESSAGE = 'The system has assigned you a 1051 new PIN of '1234', please re-enter your 1052 username and password') 1053 REPLY(Username = 'joe', Password = '1234764456') --> 1054 <-- SET(XAUTH_STATUS = OK) 1055 ACK(XAUTH_STATUS) --> 1056 1057 Example A-2: 1058 ============ 1059 Secure ID Next PIN mode via RADIUS (Scenario 2 - User generated next 1060 pin) 1061 1062 IPsec Client IPsec Gateway 1063 ------------ ------------- 1064 <-- REQUEST(Username = '', Password = '') 1065 REPLY(Username = 'joe', Password = '1637364856') --> 1066 <-- REQUEST(Username = '', Password = '', 1067 XAUTH_MESSAGE = 'Enter your new PIN containing 1068 4-6 digits') 1069 REPLY(Username = 'joe', Password = '1234') --> 1070 1071 1072Beaulieu, Pereira 18 1073 1074 Extended Authentication with ISAKMP/Oakley October 2001 1075 1076 1077 <-- REQUEST(Username = '', Password = '') 1078 REPLY(Username = 'joe', Password = '1234764456') --> 1079 <-- SET(XAUTH_STATUS = OK) 1080 ACK(XAUTH_STATUS) --> 1081 1082 1083 Example A-3: 1084 ============ 1085 1086 Secure ID Next PIN mode via RADIUS (Scenario 3 - RADIUS server 1087 offers choice of generating new PIN) 1088 1089 IPsec Client IPsec Gateway 1090 ------------ ------------- 1091 <-- REQUEST(Username = '', Password = '') 1092 REPLY(Username = 'joe', Password = '1637364856') --> 1093 <-- REQUEST(Username = '', Password = '', 1094 XAUTH_MESSAGE = 'You must start using a new 1095 PIN. Would you like to generate your own PIN 1096 (y/n)?) 1097 REPLY(Username = 'joe', Password = 'y') --> 1098 <-- REQUEST(Username = '', Password = '', XAUTH 1099 MESSAGE = 'Enter your new PIN containing 4-6 1100 digits') 1101 REPLY(Username = 'joe', Password = '1234') --> 1102 <-- REQUEST(Username = '', Password = '') 1103 REPLY(Username = 'joe', Password = '1234764456' 1104 <-- SET(XAUTH_STATUS = OK) 1105 ACK(XAUTH_STATUS) --> 1106 1107 1108 1109 Native SDI 1110 ========== 1111 1112 When doing native SDI between the edge device and the SDI server, 1113 the edge device has more information about what type of information 1114 is required from the user. The edge device can therefore use more 1115 intuitive attributes in certain situations as compared with the 1116 RADIUS examples above. 1117 1118 1119 Example A-4: 1120 ============ 1121 Secure ID Next PIN mode(Scenario 1 - SDI generated next pin) 1122 1123 1124 IPsec Client IPsec Gateway 1125 ------------ ------------- 1126 <-- REQUEST(Username = '', Passcode = '') 1127 REPLY(Username = 'joe', Passcode = '1637364856') --> 1128 <-- REQUEST(Username = '', Passcode = '', 1129 XAUTH_MESSAGE = 'The system has assigned you a 1130 1131Beaulieu, Pereira 19 1132 1133 Extended Authentication with ISAKMP/Oakley October 2001 1134 1135 1136 new PIN of '1234', please re-enter your 1137 username and passcode') 1138 REPLY(Username = 'joe', Passcode = '1234764456') --> 1139 <-- SET(STATUS = OK) 1140 ACK(STATUS) --> 1141 1142 Example A-5: 1143 ============ 1144 1145 Secure ID Next PIN mode(Scenario 2 - User generated next pin) 1146 1147 IPsec Client IPsec Gateway 1148 ------------ ------------- 1149 <-- REQUEST(Username = '', Passcode = '') 1150 REPLY(Username = 'joe', Passcode = '1637364856') --> 1151 <-- REQUEST(NEXT PIN = '', XAUTH_MESSAGE = 1152 'Enter your new PIN containing 4-6 digits') 1153 REPLY(NEXT_PIN = '1234') --> 1154 <-- REQUEST(Username = '', Passcode = '') 1155 REPLY(Username = 'joe', Passcode = '1234764456') --> 1156 <-- SET(STATUS = OK) 1157 ACK(STATUS) --> 1158 1159 1160 Example A-6: 1161 ============ 1162 Secure ID Next PIN mode(Scenario 3 - SDI server offers choice of 1163 generating new PIN) 1164 1165 IPsec Client IPsec Gateway 1166 ------------ ------------- 1167 <-- REQUEST(Username = '', Passcode = '') 1168 REPLY(Username = 'joe', Passcode = '1637364856') --> 1169 <-- REQUEST(ANSWER = '', XAUTH_MESSAGE = 'You 1170 must start using a new PIN. Would you like to 1171 generate your own PIN (y/n)?) 1172 REPLY(ANSWER = 'y') --> 1173 <-- REQUEST(NEXT_PIN = '', XAUTH MESSAGE = 1174 'Enter your new PIN containing 4-6 digits') 1175 REPLY(NEXT PIN = '1234') --> 1176 <-- REQUEST(Username = '', Passcode = '') 1177 REPLY(Username = 'joe', Passcode = '1234764456' 1178 <-- SET(STATUS = OK) 1179 ACK(STATUS) --> 1180 1181 1182 1183 1184 Example A-7: 1185 ============ 1186 SDI next cardcode 1187 1188 IPsec Client IPsec Gateway 1189 1190Beaulieu, Pereira 20 1191 1192 Extended Authentication with ISAKMP/Oakley October 2001 1193 1194 1195 ------------ ------------- 1196 <-- REQUEST(Username = '', Passcode = '') 1197 REPLY(Username = 'joe', Passcode = '1637364856') --> 1198 <-- REQUEST(Username = '', Passcode = '', 1199 XAUTH_MESSAGE = 'Your token is out of sync with 1200 the server, please enter a new passcode.') 1201 REPLY(Username = 'joe', Passcode = '1637904324') --> 1202 <-- SET(STATUS = OK) 1203 ACK(STATUS) --> 1204 1205 1206 1207 RADIUS Chap Challenge 1208 ===================== 1209 1210 Example A-8: 1211 ============ 1212 1213 1214 IPsec Client IPsec Gateway 1215 ------------ ------------- 1216 <-- REQUEST(TYPE = RADIUS-CHAP, Username = '', Password = '', 1217 Challenge = 0x01020304050607080910111213141516) 1218 REPLY(TYPE = RADIUS-CHAP, Username = 'joe', Password = 1219 '0xaa11121314151617181920212223242526') --> 1220 <-- SET(STATUS = OK) 1221 ACK(STATUS) --> 1222 1223 where the Challenge in the REQUEST is the random number generated by 1224 the edge device, and the Password in the reply contains the ID used 1225 to calculate the hash 'aa' concatenated with the hash of the 1226 (ID+secret+challenge). 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249Beaulieu, Pereira 21 1250 1251 1252 1253