1 2 3 4 5 6 7INTERNET-DRAFT M. Litvin, R. Shamir, T. Zegman 8Expires February, 2001 Check Point Software 9Category: Informational August, 2000 10 11 A Hybrid Authentication Mode for IKE 12 <draft-ietf-ipsec-isakmp-hybrid-auth-05.txt> 13 14Status of this Memo 15 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 18 19 This document is an Internet-Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working Groups. Note that other groups may also distribute 22 working documents as Internet Drafts. 23 24 Internet-Drafts draft documents are valid for a maximum of six months 25 and may be updated, replaced, or made obsolete by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 28 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 35 36 To learn the current status of any Internet-Draft, please check the 37 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 38 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 40 ftp.isi.edu (US West Coast). 41 421. Abstract 43 44 This document describes a set of new authentication methods to be 45 used within Phase 1 of the Internet Key Exchange (IKE). The proposed 46 methods assume an asymmetry between the authenticating entities. One 47 entity, typically an Edge Device (e.g. firewall), authenticates using 48 standard public key techniques (in signature mode), while the other 49 entity, typically a remote User, authenticates using challenge 50 response techniques. These authentication methods are used to 51 establish, at the end of Phase 1, an IKE SA which is unidirectionally 52 authenticated. To make this IKE bi-directionally authenticated, this 53 Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The 54 X-Auth Exchange is used to authenticate the remote User. The use of 55 56 57 58Litvin, Shamir, Zegman [Page 1] 59 60INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 61 62 63 these authentication methods is referred to as Hybrid Authentication 64 mode. 65 66 This proposal is designed to provide a solution for environments 67 where a legacy authentication system exists, yet a full public key 68 infrastructure is not deployed. 69 701.1 Reader Prerequisites 71 72 It is assumed that the reader is familiar with the terms and concepts 73 described in "Extended Authentication Within ISAKMP/Oakley" [XAUTH] 74 and "The ISAKMP Configuration Method" [IKECFG]. 75 761.2 Changes from previous version 77 781.2.1 Version 5.0 79 80 The document has undergone minor modification to prepare for for 81 independent submission as an Informational RFC. 82 83 Authentication method numbers are yet to be assigned by IANA. 84 851.2.2 Version 4.0 86 87 Authentication method numbers were assigned by IANA without altering 88 their values. 89 901.2.3 Version 3.0 91 92 Draft was renamed and reposted under the IPSRA working group. 93 941.2.4 Version 2.0 95 96 The authentication methods numbers are now taken from the private use 97 range. 98 99 Mutual authentication within Phase 1 is now discussed in [XAUTH]. 100 101 Added clarification on the use of DSS signatures. 102 103 Added clarification on the content of ID payloads sent by the Client 104 during Phase 1. 105 106 Changed the semantics of the authentication methods so that they will 107 correspond to similar authentication methods defined in [XAUTH]. 108 109 110 111 112 113 114Litvin, Shamir, Zegman [Page 2] 115 116INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 117 118 1191.2.5 Version 1.0 120 121 The draft was extensively modified since the last version. The most 122 important change is the breaking down of authentication into two 123 stages. The first stage is used to authenticate the Edge Device and 124 is based on Phase 1 Exchange, while the latter authenticates the 125 Client and is based on a Transaction Exchange [IKECFG] with the 126 mechanism described in [XAUTH]. 127 1282. Discussion 129 1302.1 Background 131 132 Several authentication methods are currently defined within IKE 133 [IKE]. These methods use either a secret which is shared by the 134 authenticating entities ("pre-shared key" method), or public key 135 cryptography ("digital signature" mode, "public key encryption" mode, 136 "revised public key encryption mode"). Legacy authentication systems, 137 such as Security Dynamics' SecurID and Axent's OmniGuard/Defender, 138 are not addressed in the current standard. 139 140 Legacy authentication systems are already deployed in many 141 organizations. These organizations may not wish to deploy a public- 142 key infrastructure in the near future. Furthermore, even if an 143 organization decides to deploy a public key infrastructure, the 144 deployment can take a considerable amount of time. Within the 145 transition period, organizations may wish to continue using their 146 legacy authentication systems. 147 1482.2 Design considerations 149 150 The currently defined IKE authentication methods share two 151 properties: the authentication is mutual (both participants 152 authenticate each other); and symmetric (both participants use the 153 same method for authentication). Mutual authentication is important 154 not only for mere identification but also to prevent man in the 155 middle attacks. 156 157 In client-server like implementations of IKE, where one of the 158 participants in the IKE is a User, while the other is an Edge Device 159 (e.g. firewall), it is not always possible to preserve symmetric 160 authentication. For example, a User can use an OmniGuard/Defender 161 token to answer an authentication challenge, but cannot issue an 162 OmniGuard/Defender authentication challenge to the firewall, since 163 she cannot check the firewall's response. 164 165 When designing an IKE authentication method that addresses legacy 166 authentication systems, it is necessary to preserve the mutual 167 168 169 170Litvin, Shamir, Zegman [Page 3] 171 172INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 173 174 175 authentication property of IKE, while its symmetric nature may be 176 violated. 177 178 The authentication methods currently defined in IKE all use a six 179 packet exchange for Main Mode, and a three packet exchange for 180 Aggressive Mode. When defining a new authentication method, which is 181 based on challenge-response authentication, it is not possible to 182 place a limitation on the number of packets that need to be exchanged 183 to authenticate a User. Usually, a simple authentication protocol 184 consists of three messages: a challenge by the Edge Device; a 185 response by the User; and a status message (authentication 186 success/failure) sent by the Edge Device. However, in many cases the 187 protocol consists of more than a single challenge-response (e.g. new 188 PIN mode of SecurID). 189 190 Due to these limitation, we divide the authentication process into 191 two stages. In the first stage, Phase 1 Exchange is being utilized to 192 authenticate the Edge Device and to establish an IKE SA. In the 193 second stage, a Transaction Exchange [IKECFG] with the mechanism 194 described in [XAUTH] is used to authenticate the Client. Even though 195 the two stages could have been integrated into a single exchange, we 196 feel that this separation, being based on existing exchanges without 197 modifying them, is easier to implement. 198 199 This proposal is suitable for environments where a legacy 200 authentication system is deployed, yet public key cryptography can be 201 used by the Edge Devices. In that case, the situation resembles the 202 way authentication is implemented in the World Wide Web using SSL. 203 The servers use public-key techniques to authenticate themselves to 204 the Users, and establish an encrypted connection. The User can then 205 authenticate herself (or send other identification information, such 206 as a credit card number). The assumption in this mode is that 207 deploying public key for a small number of entities (web servers or 208 Edge Devices) is possible without a full-public key infrastructure 209 deployment. 210 211 In some scenarios, security policy on the Edge Device might call for 212 authentication of both the User and the User's Device. In such a case 213 the Phase 1 authentication methods described in [XAUTH] should be 214 used. 215 2162.3 The hybrid authentication mode in a nut-shell 217 218 The participants in the hybrid authentication mode are typically a 219 User and an Edge Device. The participants start to negotiate, using 220 either Main Mode or Aggressive Mode, an SA in which the 221 authentication method is of a new type, indicating it is a hybrid 222 authentication method. At the end of Phase 1 the established IKE SA 223 224 225 226Litvin, Shamir, Zegman [Page 4] 227 228INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 229 230 231 is used by the Edge Device to start a Transaction Exchange [CFG] in 232 order to authenticate the User. Upon the successful completion of the 233 exchange the participants can proceed to use the IKE SA for other 234 purposes (e.g. Quick Mode). 235 2363. Terms and Definitions 237 2383.1 Requirements Terminology 239 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in [Bra97]. 243 2443.2 Definitions 245 246 The following terms are used in this document: 247 248 Edge Device - Gateway, router or firewall protecting a corporate 249 network. 250 251 User - A person trying to gain access to a corporate network 252 protected by an Edge Device. 253 254 User's Device - user's device. 255 256 Client - Denotes both the User and the User's Device. Used whenever a 257 distinction between the two terms is not necessary. 258 2593.2.1 Authentication Methods Types 260 261 The following values relate to hybrid mode authentication. Their use 262 is detailed in following sections. These values are pending 263 assignment by IANA. 264 265 Type Value 266 ------------------------------ ---------------- 267 HybridInitRSA 64221 268 HybridRespRSA 64222 269 HybridInitDSS 64223 270 HybridRespDSS 64224 271 272 2733.3 Notation 274 275 This document follows the notations defined in [IKE]. 276 2774. Description of the Hybrid Authentication Mode 278 279 280 281 282Litvin, Shamir, Zegman [Page 5] 283 284INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 285 286 287 The hybrid authentication mode is divided into two stages. The first 288 stage is a Phase 1 Exchange used to authenticate the Edge Device. The 289 exchange follows the same structure and rules as described in [IKE] 290 with some exceptions as described in the following sub-sections. The 291 Phase 1 Exchange can use either Aggressive Mode or Main Mode. The 292 initiator of the Phase 1 Exchange can be either the Client or the 293 Edge Device. The initiator of the following Transaction Exchange MUST 294 be the Edge Device. 295 296 The Phase 1 Exchange MUST be immediately followed by a Transaction 297 Exchange whose initiator is the Edge Device. The Transaction Exchange 298 MUST be protected by the IKE SA negotiated in the preceding Phase 1 299 Exchange. This IKE SA MUST NOT be used for any other exchange before 300 the Transaction Exchange terminates successfully and the User is 301 authenticated. If the User fails to authenticate the IKE SA MUST be 302 discarded. 303 304 There are two characteristics that uniquely identify a hybrid 305 authentication method: 306 307 The first is the direction of the authentication. The latter 308 determines the authentication method used to authenticate the Edge 309 Device (i.e. RSA or DSA). 310 311 For example, HybridInitRSA denotes Hybrid authentication that 312 utilizes RSA signatures in Phase 1 to authenticate the Edge Device. 313 The initiator of the Phase1 exchange is to be authenticated using 314 XAUTH. 315 316 317 318 3194.1 Bidirectional Authentication 320 321 For a discussion on how to use Bidirectional authentication together 322 with legacy authentication systems see [XAUTH]. 323 3244.2 Unidirectional Authentication 325 326 If the Client's side is not to be authenticated during the Phase 1 327 Exchange, the Phase 1 Exchange is slightly modified in the following 328 manner: 329 330 The signature payload sent by the Client SIG_I (or SIG_R) is replaced 331 with HASH_I (HASH_R), where HASH_I (HASH_R) contains the hash of the 332 data that would have otherwise be signed in SIG_I (SIG_R). Note 333 however that even if the Edge Device uses a signature scheme tied to 334 a particular hash algorithm (i.e. DSS with SHA), the negotiated prf 335 336 337 338Litvin, Shamir, Zegman [Page 6] 339 340INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 341 342 343 or the HMAC version of the negotiated hash function MUST be used by 344 the Client when computing HASH_I (HASH_R). 345 346 If a certificate request payload is sent from the Edge Device the 347 Client MUST respond with an empty certificate payload, i.e. with a 348 certificate payload whose Certificate Data field has zero length. 349 350 The ID payload sent by the Client SHOULD be left empty (i.e. with an 351 empty Identification Data field and with an ID type of zero) thus 352 providing identity protection for the Client even if Aggressive Mode 353 is used. 354 355 Examples: 356 357 Main Mode with hybrid authentication, Client initiator: 358 Initiator Responder 359 ---------- ----------- 360 HDR, SA --> 361 362 <-- HDR, SA 363 364 HDR, KE, Ni --> 365 366 <-- HDR, KE, Nr 367 368 HDR*, IDii, HASH_I --> 369 370 <-- HDR*, IDir, [ CERT, ] 371 SIG_R 372 373 XAUTH-Exchange 374 375 Aggressive Mode hybrid authentication, Edge Device initiator: 376 377 Initiator Responder 378 ----------- ----------- 379 HDR, SA, KE, Ni, IDii --> 380 381 <-- HDR, SA, KE, Nr, IDir, 382 HASH_R 383 384 HDR, [ CERT, ] SIG_I --> 385 386 XAUTH-Exchange 387 3885. Implementation hints 389 390 Since the Edge Device always initiates the Transaction Exchange, when 391 392 393 394Litvin, Shamir, Zegman [Page 7] 395 396INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 397 398 399 a Client initiates the Phase 1 Exchange, the authentication methods 400 included in the Client's proposal should be either HybridInitRSA or 401 HybridInitDSS, whereas if the Edge Device is the initiator of the 402 Phase 1 Exchange the authentication methods included in the Edge 403 Device's proposal should be either HybridRespRSA or HybridRespDSS. 404 4056. Security Considerations 406 407 This document describes a protocol to be used to establish an IKE SA. 408 The level of security the protocol provides, relies among other 409 things, on the strength of the authentication mechanism used to 410 authenticate the Client. 411 412 While pre-shared key authentication for mobile users can be done only 413 in Aggressive Mode, thus revealing the identity of the User, these 414 proposed methods provide, when used in conjunction with Aggressive 415 Mode, User's identity protection and when used in conjunction with 416 Main Mode, provide identity protection for both parties. 417 418 While the authors greatly discourage the use of fixed passwords, 419 these methods have another advantage over the pre-shared key method: 420 The password is not prone to offline dictionary attacks, since the 421 password is encrypted using a derivative of the Diffie-Hellman shared 422 key. Only the participants in the IKE protocol know the shared key. 423 424 NB: When using standard IKE authentication methods both parties can 425 (and must) detect man-in-the-middle attacks. When one uses hybrid 426 authentication to establish unidirectional authenticated IKE SA's, 427 only the Client can (and must) detect these kinds of attacks. 428 429 This proposal does not provide protection against denial of service 430 attacks in which an attacker, impersonating a User, repeatedly tries 431 to authenticate, eventually causing the User's account to be revoked. 432 Nonetheless, this kind of weakness is inherent to challenge-response 433 techniques and should not be considered a weakness of this protocol 434 but of the authentication methods it utilizes. 435 4367. Acknowledgements 437 438 The authors would like to thank Roy Pereira, Tim Jenkins, Paul 439 Kierstead and Stephen Kent for their comments and contributions to 440 this document. 441 442 443 444 445 446 447 448 449 450Litvin, Shamir, Zegman [Page 8] 451 452INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 453 454 4558. References 456 457 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 458 Requirement Levels", RFC2119 459 460 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 461 RFC2409 462 463 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, 464 J., "Internet Security Association and Key Management Protocol 465 (ISAKMP)", RFC2408. 466 467 [IKECFG] R. Pereira, S. Anand, B. Patel, "The ISAKMP Configuration 468 Method", draft-ietf-ipsec-isakmp-mode-cfg-05.txt, work in progress. 469 470 [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication Within 471 ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-06.txt, work in 472 progress. 473 474 475Author Addresses: 476 477 Moshe Litvin <moshe@checkpoint.com> 478 Check Point 479 3A Jabotinsky St. 480 Ramat-Gan 52520 481 ISRAEL 482 483 484 Roy Shamir <roy@checkpoint.com> 485 Check Point 486 3A Jabotinsky St. 487 Ramat-Gan 52520 488 ISRAEL 489 490 491 Tamir Zegman <zegman@checkpoint.com> 492 Check Point 493 3A Jabotinsky St. 494 Ramat-Gan 52520 495 ISRAEL 496 497 498Full Copyright Statement: 499 500 Copyright (C) The Internet Society (2000). All Rights Reserved. 501 502 This document and translations of it may be copied and furnished to 503 504 505 506Litvin, Shamir, Zegman [Page 9] 507 508INTERNET DRAFT A Hybrid Authentication Mode for IKE August, 2000 509 510 511 others, and derivative works that comment on or otherwise explain it 512 or assist in its implementation may be prepared, copied, published 513 and distributed, in whole or in part, without restriction of any 514 kind, provided that the above copyright notice and this paragraph 515 are included on all such copies and derivative works. However, this 516 document itself may not be modified in any way, such as by removing 517 the copyright notice or references to the Internet Society or other 518 Internet organizations, except as needed for the purpose of 519 developing Internet standards in which case the procedures for 520 copyrights defined in the Internet Standards process must be 521 followed, or as required to translate it into languages other than 522 English. 523 524 The limited permissions granted above are perpetual and will not be 525 revoked by the Internet Society or its successors or assigns. 526 527 This document and the information contained herein is provided on an 528 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 529 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 530 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 531 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 532 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562Litvin, Shamir, Zegman [Page 10] 563 564