idnits 2.17.1 draft-ietf-ipsec-isakmp-xauth-05.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. == 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. ** 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 (March 1, 2000) is 8821 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 150, but not defined == Missing Reference: 'Thayer97' is mentioned on line 150, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 153, 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 March 1, 2000 5 September 1, 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 (IPSEC) Working Group. Comments are solicited and should 17 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 Sep-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 Extended Authentication Method.....................................4 69 2.1 Simple Authentication............................................5 70 2.2 Challenge/Response...............................................5 71 2.3 Two-Factor Authentication........................................6 72 2.4 One-Time-Password................................................7 73 2.5 User Previously Authenticated....................................7 74 2.6 Other Useful Examples............................................7 75 3 Extensions to ISAKMP-Config........................................7 76 3.1 Message Types....................................................8 77 3.2 Attributes.......................................................9 78 3.3 Authentication Types............................................10 79 4 Authentication Method Types.......................................11 80 5 Other Scenarios for Extended Authentication.......................13 81 6 Security Considerations...........................................13 82 7 References........................................................13 83 8 Acknowledgements..................................................14 84 9 Authors' Addresses................................................15 85 10 Expiration.......................................................15 86 11 Full Copyright Statement.........................................15 87 Appendix A..........................................................17 89 1 Introduction 91 The following technique allows IPSec's ISAKMP/Oakley [IKE] protocol 92 to support extended authentication mechanisms like two-factor 93 authentication, challenge/response and other remote access 94 unidirectional authentication methods. 96 Internet Draft Sep-99 98 These authentication mechanisms have a large deployment in remote 99 access applications and many IT departments have requirements for 100 these unidirectional authentication mechanisms. 102 1.1 Changes Since Last Revision 104 o The last revision of this document was published in the IPSec 105 Working Group as 106 108 o Added text which allows multiple authentication mechanisms to be 109 used within one XAUTH transaction. 111 o Added examples of RADIUS CHAP, and Secure ID next PIN mode in 112 Appendix A 114 o Added text which describes how to retry if a user�s input fails 115 to be authenticated. 117 o The ISAKMP Message ID now follows the rules defined by the 118 ISAKMP-Config draft. 120 o XAUTH_REQ_NUMBER has been removed 122 1.2 Extended Authentication 124 Two-factor authentication and challenge/response schemes like SDI's 125 SecurID and RADIUS are forms of authentication that allow a 126 gateway, firewall, or network access server to offload the user 127 administration and authentication to a central management server. 128 IPSec's ISAKMP/Oakley protocol supports certificates (RSA & DSS), 129 shared-secret, and Kerberos as authentication methods, but since 130 the authentication methods described within this document are only 131 unidirectional authentication methods (client to a 132 gateway/firewall), they cannot be used by themselves, but must be 133 used in conjunction with the other standard ISAKMP authentication 134 methods. 136 The technique described within this document utilizes ISAKMP to 137 transfer the user's authentication information (name, password) to 138 the gateway/firewall (edge device) in a secured ISAKMP message. The 139 edge device would then use either the appropriate protocol (RADIUS, 140 SecurID, OTP) to authenticate the user. This allows the 141 authentication server to be within the private network that the 142 edge device is protecting. 144 Internet Draft Sep-99 146 1.3 Reader Prerequisites 148 It is assumed that the reader is familiar with the terms and 149 concepts described in the "Security Architecture for the Internet 150 Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] 151 documents. 153 Readers are advised to be familiar with both [IKE] and [ISAKMP] as 154 well as [IKECFG] since this document is an extension to that 155 document. 157 1.4 Specification of Requirements 159 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 160 NOT", and "MAY" that appear in this document are to be interpreted 161 as described in [Bradner97]. 163 2 Extended Authentication Method 165 This specification allows for extended authentication by allowing 166 an edge device to request extended authentication from an IPSec 167 host (end-node), thus forcing the host to respond with its extended 168 authentication credentials. The edge device will then respond with 169 a failed or passed message. 171 When the edge device requests extended authentication, it will 172 specify the type of extra authentication and any parameters 173 required for it. These parameters MAY be the attributes that it 174 requires for authentication and they MAY be information required 175 for the IPSec host's reply (e.g. challenge string). 177 The last message sent by the edge device is simply a reply denoting 178 failure or success. The reply MAY have some textual information 179 describing the reason for the failure or success. The edge device 180 MAY also request another authentication, like SecurID's next PIN 181 request, where the user is required to enter the next passcode to 182 further verify itself. 184 As with CHAP [CHAP], this protocol can also be used to periodically 185 authenticate the user during the lifetime of a security 186 association. 188 If the IPSec host does not have support for the authentication 189 method requested by the edge device, then it would send back a 190 reply with empty attributes, thus failing the authentication but 191 completing the transaction. The last exchange (SET/ACK) MUST also 192 be completed. 194 Internet Draft Sep-99 196 The Extended Authentication mechanism does not replace the IKE 197 Phase 1 authentication mechanisms. It simply extends them by 198 allowing devices to do two different authentication schemes. Both 199 peers SHOULD still authenticate each other via the authentication 200 methods described in [IKE]. 202 This method provides unidirectional authentication only, meaning 203 that only one device is authenticated using both IKE authentication 204 methods and Extended Authentication. 206 Here are some types of extended authentication that this 207 specification supports: 209 2.1 Simple Authentication 211 Where a user name and password are required for authentication. 213 IPSec Host Edge Device 214 -------------- ----------------- 215 <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="") 216 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar") --> 217 <-- SET(STATUS=OK) 218 ACK(STATUS) --> 220 Some authentication mechanisms hide the user password by some type 221 of encryption mechanism. 223 IPSec Host Edge Device 224 -------------- ----------------- 225 <-- REQUEST(TYPE=RADIUS CHALLENGE="123456" 226 NAME="" PASSWORD="") 227 REPLY(TYPE=RADIUS NAME="joe" PASSWORD="E4901AB7") --> 228 <-- SET(STATUS=OK) 229 ACK(STATUS) --> 231 2.2 Challenge/Response 233 Where a challenge from the edge device must be incorporated with 234 the reply. This makes each reply different. 236 IPSec Host Edge Device 237 -------------- ----------------- 238 <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="") 239 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar") --> 240 <-- REQUEST(TYPE=GENERIC MESSAGE="Enter your password 241 followed by your pin number" NAME="" PASSWORD="") 242 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") --> 243 <-- SET(STATUS=OK) 245 Internet Draft Sep-99 247 ACK(STATUS) --> 249 If, however, the edge device knows that a challenge will be 250 required it may skip the first exchange as follows: 252 IPSec Host Edge Device 253 -------------- ----------------- 254 <-- REQUEST(TYPE=GENERIC MESSAGE="Enter your password 255 followed by your pin number" NAME="" PASSWORD="") 256 REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") --> 257 <-- SET(STATUS=OK) 258 ACK(STATUS) --> 260 2.3 Two-Factor Authentication 262 This authentication method combines something the user knows (their 263 password) and something that the user has (a token card). 265 IPSec Host Edge Device 266 -------------- ----------------- 267 <-- REQUEST(TYPE=GENERIC NAME="" 268 PASSWORD="" PASSCODE="") 269 REPLY(TYPE=GENERIC NAME="joe" 270 PASSWORD="foobar" PASSCODE="3412") --> 271 <-- SET(STATUS=OK) 272 ACK(STATUS) --> 274 Some mechanisms allow for another optional request of the passcode. 276 IPSec Host Edge Device 277 -------------- ----------------- 278 <-- REQUEST(TYPE=GENERIC NAME="" 279 PASSWORD="" PASSCODE="") 280 REPLY(TYPE=GENERIC NAME="joe" 281 PASSWORD="foobar" PASSCODE="323415") --> 282 <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="" 283 PASSCODE="") 284 REPLY(TYPE=GENERIC NAME="joe" 285 PASSWORD="foobar" PASSCODE="513212") --> 286 <-- SET(STATUS=OK) 287 ACK(STATUS) --> 289 Internet Draft Sep-99 291 2.4 One-Time-Password 293 Similar to the Challenge/Response method, this method allows 294 authentication that is secure against passive attacks based on 295 replaying captured passwords. 297 IPSec Host Edge Device 298 -------------- ----------------- 299 <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" 300 NAME="" PASSWORD="") 301 REPLY(TYPE=OTP NAME="joe" 302 PASSWORD="5bf0 75d9 959d 036f") --> 303 <-- SET(STATUS=OK) 304 ACK(STATUS) --> 306 2.5 User Previously Authenticated 308 Some situations may occur where the edge device has already 309 authenticated the host and no new authentication is required. This 310 may happen when either the host or the edge device must rekey an 311 existing phase 1 SA. The edge device is not sure who the peer is 312 because the phase 1 ID is not transmitted until after the proposal 313 payloads are exchange. In this case, the peers may agree to do 314 XAUTH even though the remote user still has a valid XAUTH 315 authentication. In such a scenario, this method MAY be used to 316 avoid prompting the user. Edge devices MUST NOT use this 317 authentication method in cases where the phase 1 ID does not match 318 the previous phase 1 ID. 320 In these situations, the following method is used. 322 IPSec Host Edge Device 323 ------------- ---------------- 324 <-- SET(STATUS=OK) 325 ACK(STATUS) --> 327 2.6 Other Useful Examples 329 More useful examples are found in Appendix A. 331 3 Extensions to ISAKMP-Config 333 This protocol uses the mechanisms described in ISAKMP-Config 334 [IKECFG] to accomplish its authentication transaction. 336 All ISAKMP-Config messages in an extended authentication 337 transaction MUST contain the same ISAKMP-Config transaction 338 identifier. The Message ID in the ISAKMP header follows the rules 339 defined by the ISAKMP-Config protocol. 341 Internet Draft Sep-99 343 This protocol can therefore be used in conjunction with any 344 existing basic ISAKMP authentication method as defined in [IKE]. 345 If mutual authentication is not required, then the phase 1 346 negotiation MAY use an authentication method of shared-secret and 347 have that shared-secret be null. However, this is STRONGLY 348 DISCOURAGED since the edge-device is NOT authenticated. See the 349 Security Considerations section for more detail. 351 This authentication MUST be used after a phase 1 exchange has 352 completed and before any other exchange with the exception of Info 353 mode exchanges. If the extended authentication fails, then the 354 phase 1 SA MUST be immediately deleted. The edge device MAY choose 355 to retry an extended authentication request if the user failed to 356 be authenticated, but must do so in the same ISAKMP-Config 357 transaction, and MUST NOT send the SET message until the user is 358 authenticated, or until the edge device wishes to stop retrying and 359 fail the user. 361 Extended Authentication MAY be initiated by the edge device at any 362 time after the initial authentication exchange. For example, 363 RADIUS servers may specify that a user only be authenticated for a 364 certain time period. Once that time period has elapsed (minus a 365 possible jitter), the edge device may request a new Extended 366 Authentication exchange. If the Extended Authentication exchange 367 fails, the edge device MUST tear down all phase 1 and phase 2 SAs 368 associated with the user. 370 The following are extensions to the ISAKMP-Config [IKECFG] 371 specification to support Extended Authentication. 373 3.1 Message Types 375 Type Value 376 -------------------------- ----------------------------- 377 ISAKMP_CFG_REQUEST ( as defined in [IKECFG] ) 378 ISAKMP_CFG_REPLY ( as defined in [IKECFG] ) 379 ISAKMP_CFG_SET ( as defined in [IKECFG] ) 380 ISAKMP_CFG_ACK ( as defined in [IKECFG] ) 382 o ISAKMP_CFG_REQUEST - This message is sent from an edge device to 383 an IPSec host trying to request extended authentication. 384 Attributes that it requires sent back in the reply MUST be 385 included with a length of zero (0). Attributes required for the 386 authentication reply, such as a challenge string MUST be included 387 with the proper values filled in. 389 o ISAKMP_CFG_REPLY - This message MUST contain the filled in 390 authentication attributes that were requested by the edge device. 392 Internet Draft Sep-99 394 o ISAKMP_CFG_SET - This message is sent from an edge device and is 395 only used, within the scope of this document, to state the 396 success of the authentication. This message MUST only include 397 the success of failure of the authentication and MAY contain some 398 clarification text. 400 o ISAKMP_CFG_ACK - This message is sent from the IPSec host 401 acknowledging receipt of the authentication result. Its 402 attributes are not relevant and MAY be skipped entirely, thus no 403 attributes SHOULD be included. This last message in the 404 authentication transaction is used solely as an acknowledgement 405 of the previous message and to eliminate problems with 406 unacknowledged messages over UDP. 408 3.2 Attributes 410 Attribute Value Type 411 --------------------- ------ --------------------- 412 XAUTH_TYPE 13 Basic 413 XAUTH_USER_NAME 14 Variable ASCII string 414 XAUTH_USER_PASSWORD 15 Variable ASCII string 415 XAUTH_PASSCODE 16 Variable ASCII string 416 XAUTH_MESSAGE 17 Variable ASCII string 417 XAUTH_CHALLENGE 18 Variable ASCII string 418 XAUTH_DOMAIN 19 Variable ASCII string 419 XAUTH_STATUS 20 Basic 421 o XAUTH_TYPE - The type of extended authentication requested whose 422 values are described in the next section. This is a mandatory 423 attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY 424 messages. The XAUTH_TYPE in a REPLY MUST be identical to the 425 XAUTH_TYPE in the REQUEST. However, an XAUTH transaction MAY 426 have multiple REQUEST/REPLY pairs with different XAUTH_TYPE 427 values in each pair. 429 o XAUTH_USER_NAME - The user name MAY be any unique identifier of 430 the user such as a login name, an email address, or a X.500 431 Distinguished Name. 433 o XAUTH_USER_PASSWORD - The user's password. 435 o XAUTH_PASSCODE - A token card's passcode. This SHOULD only be 436 used when the password attribute is also used. 438 o XAUTH_MESSAGE - A textual message from an edge device to an IPSec 439 host. The message may contain a textual challenge or 440 instruction. An example of this would be "Enter your password 441 followed by your pin number". The message may also contain a 443 Internet Draft Sep-99 445 reason why authentication failed or succeeded. This message 446 SHOULD be displayed to the user. 448 o XAUTH_CHALLENGE - A challenge string sent from the edge device to 449 the IPSec host for it to include in its calculation of a 450 password. This attribute SHOULD only be sent in an 451 ISAKMP_CFG_REQUEST message. Typically, the XAUTH_TYPE attribute 452 dictates how the receiving device should handle the challenge. 453 For example, RADIUS uses the challenge to hide the password. 455 o XAUTH_DOMAIN - The domain to be authenticated in. This value 456 will have different meaning depending on the authentication type. 458 o XAUTH_STATUS - A variable that is used to denote authentication 459 success (OK=1) or failure (FAIL=0). This is a mandatory 460 attribute for the ISAKMP_CFG_SET message. 462 3.3 Authentication Types 464 Value Authentication Required 465 ----- --------------------------------- 466 0 Generic 467 1 RADIUS 468 2 OTP 469 3 NT Domain 470 4 Unix Login 471 5 SDI SecurID 472 6 AXENT Defender 473 7 LeeMah InfoCard 474 8 ActiveCard 475 9 Secure Computing Enigma (DES Gold) 476 10 TACACS 477 11 TACACS+ 478 12 S/KEY 479 13 NDS (Netware Directory Services) 480 14 DIAMETER 481 15 LDAP 482 16-32767 Reserved for future use 483 32768-65535 Reserved for private use 485 o Generic - A catch-all type that allows for future extensibility 486 and a generic mechanism to request authentication information. 487 This method allows for any type of extended authentication which 488 does not require specific processing, and should be used whenever 489 possible. 491 o RADIUS - A RADIUS [RADIUS] server requires at least a user name 492 and a password, but since RADIUS may be proxying for another type 494 Internet Draft Sep-99 496 of authentication method, both the request and the reply MAY be 497 like any of the other extended authentication types. 499 o OTP - One-Time-Passwords as defined in [OTP] uses a challenge 500 string to request a certain generated password. The request 501 SHOULD contain a user name, password and a challenge string while 502 the reply MUST contain the user name and the generated password. 503 The challenge string is formatted as defined in [OTPEXT]. 505 o NT Domain - This authentication type provides for user 506 authentication by login into a Windows NT(r) domain. The request 507 SHOULD contain empty user name, password and domain attributes. 508 The reply MUST contain all of these attributes filled in. The 509 domain attribute is optional for both messages, and SHOULD NOT be 510 included in the reply if it isn�t included in the request. 512 o Unix Login - Much like the NT Domain authentication type, but 513 this will authenticate the user to a Unix(r) workstation. 515 o SDI SecurID, AXENT Defender, LeeMah InfoCard, ActiceCard, 516 Enigma/DES Gold - All of these (and others) use smart cards to 517 generate a 'passcode' to authenticate the user. This passcode 518 combined with the user's password provides stronger 519 authentication than just passwords. The response MUST include 520 the user name, password and the token card's passcode. This 521 authentication type MIGHT also include a challenge string in the 522 request. 524 o TACACS - Defined in [TACACS], this authentication protocol was 525 the precursor to RADIUS, thus the same rules apply. 527 o TACACS+ - Defined in [TACACS+], this authentication protocol is 528 an updated version of the original TACACS protocol, thus the same 529 rules apply. 531 o S/KEY - This one-time-password scheme defined in [SKEY] was the 532 precursor to OTP, thus the same rules applies. 534 o NDS - Much like the NT Domain authentication type, but this will 535 authenticate the user to a NetWare Directory server. 537 o DIAMETER - The next generation RADIUS protocol that is defined in 538 [DIAMETER]. The same rules as RADIUS apply. 540 4 Authentication Method Types 542 The following values relate to the ISAKMP authentication method 543 attribute used in proposals. They optionally allow an XAUTH 545 Internet Draft Sep-99 547 implementation to propose use of extended authentication after the 548 initial phase 1 authentication. Values are taken from the private 549 use range defined in [IKE] and should be used among mutually 550 consenting parties. 552 Method Value 553 ------------------------------ ----- 554 XAUTHInitPreShared 65001 555 XAUTHRespPreShared 65002 556 XAUTHInitDSS 65003 557 XAUTHRespDSS 65004 558 XAUTHInitRSA 65005 559 XAUTHRespRSA 65006 560 XAUTHInitRSAEncryption 65007 561 XAUTHRespRSAEncryption 65008 562 XAUTHInitRSARevisedEncryption 65009 563 XAUTHRespRSARevisedEncryption 65010 565 An Extended Authentication proposal has two characteristics. 567 The first is the direction of the authentication. Each type 568 identifies whether the Initiator or the Resonder is the device 569 which should be authenticated using XAUTH. For example 570 XAUTHInitPreShared is a type which demands that the Initiator be 571 authenticated. 573 Note that an edge device would typically initiate with one of the 574 following: 575 o XAUTHRespPreShared 576 o XAUTHRespDSS 577 o XAUTHRespRSA 578 o XAUTHRespRSAEncryption 579 o XAUTHRespRSARevisedEncryption 581 and would typically only accept proposals with the following 582 authentication methods: 583 o XAUTHInitPreShared 584 o XAUTHInitDSS 585 o XAUTHInitRSA 586 o XAUTHInitRSAEncryption 587 o XAUTHInitRSARevisedEncryption 589 The second characteristic is the IKE Authentication method to be 590 used. The following table illustrates which keywords in the 591 methods described above relate to which Authentication Methods 592 described in [IKE] Appendix A. 594 Internet Draft Sep-99 596 "PreShared" -> pre-shared key 597 "DSS" -> DSS signatures 598 "RSA" -> RSA signatures 599 "RSAEncryption" -> Encryption with RSA 600 "RSARevisedEncryption" -> Revised encryption with RSA 602 5 Other Scenarios for Extended Authentication 604 Although this document described a scenario where an IPSec host 605 (eg. mobile user) was being authenticated by an edge device (eg. 606 firewall/gateway), the methods described can also be used for edge 607 device to edge device authentication as well as IPSec host to IPSec 608 host authentication. 610 6 Security Considerations 612 Care should be taken when sending sensitive information over public 613 networks such as the Internet. A user's password should never be 614 sent in the clear and when sent encrypted, the destination MUST 615 have been previously authenticated. The use of ISAKMP-Config 616 [IKECFG] addresses these issues. 618 The use of Extended Authentication does not imply that phase 1 619 authentication is no longer needed. Phase 1 authentication provides 620 a higher level of user authentication by signing ISAKMP packets. 621 Extended Authentication does not provide this service. The removal 622 or weakening of phase 1 authentication would leave the IPSec 623 session vulnerable to a man-in-the-middle attack and other spoofing 624 attacks. Therefore, when using Extended Authentication with Pre- 625 Shared keys, it is vital that the Pre-Shared key be well chosen and 626 secure. 628 7 References 630 [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate 631 Requirement Levels", RFC2119 633 [CHAP] W. Simpson, "PPP Challenge Handshake Authentication 634 Protocol (CHAP)", RFC1994 636 [DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 637 draft-calhoun-diameter-02.txt 639 [HYBRID] M. Litvin, R. Shamir, T. Zegman, "A Hybrid 640 Authentication Mode for IKE", draft-ietf-ipsec- 641 isakmp-hybrid-auth-01 643 Internet Draft Sep-99 645 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange 646 (IKE)", RFC2409 648 [IKECFG] R. Pereira, "The ISAKMP Configuration Method", 649 draft-ietf-ipsec-isakmp-cfg-05 651 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, 652 "Remote Authentication Dial In User Service 653 (RADIUS)", RFC2138 655 [OTP] N. Haller, C. Metz, "A One-Time Password System", 656 RFC1938 658 [SKEY] N. Haller, "The S/KEY One-Time Password System", 659 RFC1760 661 [TACACS] C. Finseth, "An Access Control Protocol, Sometimes 662 Called TACACS", RFC1492 664 [TACACS+] D. Carrel, L. Grant, "The TACACS+ Protocol Version 665 1.77", draft-grant-tacacs-01.txt 667 [OTPEXT] C. Metz, "OTP Extended Responses", RFC 2243 669 8 Acknowledgements 671 The internet-draft "A Hybrid Authentication Mode for IKE" helped us further enhance 673 this specification. The concept of using new Authentication Method 674 identifiers in the SA payload in order to accomplish extended 675 authentication originated in the [HYBRID] draft. 677 Internet Draft Sep-99 679 9 Authors' Addresses 681 Roy Pereira 682 683 TimeStep Corporation 684 +1 (613) 599-3610 x 4808 686 Stephane Beaulieu 687 688 TimeStep Corporation 689 +1 (613) 599-3610 x 4709 691 The IPSec working group can be contacted via the IPSec working 692 group's mailing list (ipsec@lists.tis.com) or through its chairs: 694 Robert Moskowitz 695 rgm@icsa.net 696 Internal Computer Security Association 698 Theodore Y. Ts'o 699 tytso@MIT.EDU 700 Massachusetts Institute of Technology 702 10 Expiration 704 This draft expires March 1, 2000 706 11 Full Copyright Statement 708 Copyright (C) The Internet Society (1998). All Rights Reserved. 710 This document and translations of it may be copied and furnished to 711 others, and derivative works that comment on or otherwise explain 712 it or assist in its implementation may be prepared, copied, 713 published and distributed, in whole or in part, without restriction 714 of any kind, provided that the above copyright notice and this 715 paragraph are included on all such copies and derivative works. 716 However, this document itself may not be modified in any way, such 717 as by removing the copyright notice or references to the Internet 718 Society or other Internet organizations, except as needed for the 719 purpose of developing Internet standards in which case the 720 procedures for copyrights defined in the Internet Standards process 721 must be followed, or as required to translate it into languages 722 other than English. 724 The limited permissions granted above are perpetual and will not be 725 revoked by the Internet Society or its successors or assigns. 727 Internet Draft Sep-99 729 This document and the information contained herein is provided on 730 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 731 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 732 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 733 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 734 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 736 Internet Draft Sep-99 738 Appendix A 740 This appendix gives more useful examples of Extended 741 Authentication. 743 Secure ID Next PIN mode 744 ======================= 746 Ipsec Client Ipsec Gateway 747 ------------ ------------- 748 <-- REQUEST(TYPE = Generic, Username = '', Passcode = '') 749 REPLY(TYPE = Generic, Username = 'joe', 750 Passcode = '1637364856') --> 751 <-- REQUEST(TYPE = Generic, Username = '', Password = '', 752 XAUTH_MESSAGE = 'The system has assigned you a new 753 PIN, do you wish to see it now?') 754 REPLY(TYPE = Generic, Username = 'joe', Password = 'y') --> 755 <-- REQUEST(TYPE = Generic, Username = '', XAUTH_MESSAGE 756 = 'Your new pin is 1234' 757 REPLY(TYPE = Generic, Username = 'joe', 758 Passcode = '1234764456') --> 759 <-- SET(XAUTH_STATUS = OK) 760 ACK(XAUTH_STATUS) --> 762 RADIUS Chap Challenge 763 ===================== 765 Ipsec Client Ipsec Gateway 766 ------------ ------------- 767 <-- REQUEST(TYPE = RADIUS, Username = '', Password = '', 768 Challenge = 0x01020304050607080910111213141516) 769 REPLY(TYPE = RADIUS, Username = 'joe', Password = 770 '0xaa11121314151617181920212223242526') --> 771 <-- SET(XAUTH_STATUS = OK) 772 ACK(XAUTH_STATUS) --> 774 where the Challenge in the REQUEST is the random number generated 775 by the edge device, and the Password in the reply contains the ID 776 used to calculate the hash 'aa' concatenated with the hash of the 777 (ID+challenge+secret)