idnits 2.17.1 draft-ietf-ipsec-isakmp-hybrid-auth-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 an Authors' Addresses Section. ** 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 ([XAUTH]), 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'CFG' is mentioned on line 184, but not defined == Unused Reference: 'ISAKMP' is defined on line 374, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- Possible downref: Normative reference to a draft: ref. 'IKECFG' -- Possible downref: Normative reference to a draft: ref. 'XAUTH' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Secure Remote Access Working Group M. Litvin, R. Shamir, T. Zegman 2 INTERNET-DRAFT Check Point Software 3 draft-ietf-ipsec-isakmp-hybrid-auth-03.txt December, 1999 4 Expires May, 2000 6 A Hybrid Authentication Mode for IKE 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is a submission to the IETF Internet Protocol Secure 15 Remote Access (IPSRA) Working Group. Comments are solicited and 16 should be addressed to the working group mailing list (ietf- 17 ipsra@vpnc.org) or to the editor. 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. 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." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To learn the current status of any Internet-Draft, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 38 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 39 ftp.isi.edu (US West Coast). 41 1. Abstract 43 This document describes a set of new authentication methods to be 44 used within Phase 1 of the Internet Key Exchange (IKE). The proposed 45 methods assume an asymmetry between the authenticating entities. One 46 entity, typically an Edge Device (e.g. firewall), authenticates using 47 standard public key techniques (in signature mode), while the other 48 entity, typically a remote User, authenticates using challenge 49 response techniques. These authentication methods are used to 50 establish, at the end of Phase 1, an IKE SA which is unidirectionally 51 authenticated. To make this IKE bi-directionally authenticated, this 52 Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The 53 X-Auth Exchange is used to authenticate the remote User. The use of 54 these authentication methods is referred to as Hybrid Authentication 55 mode. 57 This proposal is designed to provide a solution for environments 58 where a legacy authentication system exists, yet a full public key 59 infrastructure is not deployed. 61 1.1 Reader Prerequisites 63 It is assumed that the reader is familiar with the terms and concepts 64 described in "Extended Authentication Within ISAKMP/Oakley" [XAUTH] 65 and "The ISAKMP Configuration Method" [IKECFG]. 67 1.2 Changes from previous version 69 1.2.2 Version 3.0 71 Draft was renamed and reposted under the IPSRA working group. 73 1.2.2 Version 2.0 75 The authentication methods numbers are now taken from the private use 76 range. 78 Mutual authentication within Phase 1 is now discussed in [XAUTH]. 80 Added clarification on the use of DSS signatures. 82 Added clarification on the content of ID payloads sent by the Client 83 during Phase 1. 85 Changed the semantics of the authentication methods so that they will 86 correspond to similar authentication methods defined in [XAUTH]. 88 1.2.3 Version 1.0 90 The draft was extensively modified since the last version. The most 91 important change is the breaking down of authentication into two 92 stages. The first stage is used to authenticate the Edge Device and 93 is based on Phase 1 Exchange, while the latter authenticates the 94 Client and is based on a Transaction Exchange [IKECFG] with the 95 mechanism described in [XAUTH]. 97 2. Discussion 99 2.1 Background 101 Several authentication methods are currently defined within IKE 102 [IKE]. These methods use either a secret which is shared by the 103 authenticating entities ("pre-shared key" method), or public key 104 cryptography ("digital signature" mode, "public key encryption" mode, 105 "revised public key encryption mode"). Legacy authentication systems, 106 such as Security Dynamics' SecurID and Axent's OmniGuard/Defender, 107 are not addressed in the current standard. 109 Legacy authentication systems are already deployed in many 110 organizations. These organizations may not wish to deploy a public- 111 key infrastructure in the near future. Furthermore, even if an 112 organization decides to deploy a public key infrastructure, the 113 deployment can take a considerable amount of time. Within the 114 transition period, organizations may wish to continue using their 115 legacy authentication systems. 117 2.2 Design considerations 119 The currently defined IKE authentication methods share two 120 properties: the authentication is mutual (both participants 121 authenticate each other); and symmetric (both participants use the 122 same method for authentication). Mutual authentication is important 123 not only for mere identification but also to prevent man in the 124 middle attacks. 126 In client-server like implementations of IKE, where one of the 127 participants in the IKE is a User, while the other is an Edge Device 128 (e.g. firewall), it is not always possible to preserve symmetric 129 authentication. For example, a User can use an OmniGuard/Defender 130 token to answer an authentication challenge, but cannot issue an 131 OmniGuard/Defender authentication challenge to the firewall, since 132 she cannot check the firewall's response. 134 When designing an IKE authentication method that addresses legacy 135 authentication systems, it is necessary to preserve the mutual 136 authentication property of IKE, while its symmetric nature may be 137 violated. 139 The authentication methods currently defined in IKE all use a six 140 packet exchange for Main Mode, and a three packet exchange for 141 Aggressive Mode. When defining a new authentication method, which is 142 based on challenge-response authentication, it is not possible to 143 place a limitation on the number of packets that need to be exchanged 144 to authenticate a User. Usually, a simple authentication protocol 145 consists of three messages: a challenge by the Edge Device; a 146 response by the User; and a status message (authentication 147 success/failure) sent by the Edge Device. However, in many cases the 148 protocol consists of more than a single challenge-response (e.g. new 149 PIN mode of SecurID). 151 Due to these limitation, we divide the authentication process into 152 two stages. In the first stage, Phase 1 Exchange is being utilized to 153 authenticate the Edge Device and to establish an IKE SA. In the 154 second stage, a Transaction Exchange [IKECFG] with the mechanism 155 described in [XAUTH] is used to authenticate the Client. Even though 156 the two stages could have been integrated into a single exchange, we 157 feel that this separation, being based on existing exchanges without 158 modifying them, is easier to implement. 160 This proposal is suitable for environments where a legacy 161 authentication system is deployed, yet public key cryptography can be 162 used by the Edge Devices. In that case, the situation resembles the 163 way authentication is implemented in the World Wide Web using SSL. 164 The servers use public-key techniques to authenticate themselves to 165 the Users, and establish an encrypted connection. The User can then 166 authenticate herself (or send other identification information, such 167 as a credit card number). The assumption in this mode is that 168 deploying public key for a small number of entities (web servers or 169 Edge Devices) is possible without a full-public key infrastructure 170 deployment. 172 In some scenarios, security policy on the Edge Device might call for 173 authentication of both the User and the User's Device. In such a case 174 the Phase 1 authentication methods described in [XAUTH] should be 175 used. 177 2.3 The hybrid authentication mode in a nut-shell 179 The participants in the hybrid authentication mode are typically a 180 User and an Edge Device. The participants start to negotiate, using 181 either Main Mode or Aggressive Mode, an SA in which the 182 authentication method is of a new type, indicating it is a hybrid 183 authentication method. At the end of Phase 1 the established IKE SA 184 is used by the Edge Device to start a Transaction Exchange [CFG] in 185 order to authenticate the User. Upon the successful completion of the 186 exchange the participants can proceed to use the IKE SA for other 187 purposes (e.g. Quick Mode). 189 3. Terms and Definitions 190 3.1 Requirements Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [Bra97]. 196 3.2 Definitions 198 The following terms are used in this document: 200 Edge Device - Gateway, router or firewall protecting a corporate 201 network. 203 User - A person trying to gain access to a corporate network 204 protected by an Edge Device. 206 User's Device - user's device. 208 Client - Denotes both the User and the User's Device. Used whenever a 209 distinction between the two terms is not necessary. 211 3.2.1 Authentication Methods Types 213 The following values relate to hybrid mode authentication. Their use 214 is detailed in following sections. Values are taken from the private 215 use range defined in [IKE] and should be used among mutually 216 consenting parties. 218 Type Value 219 ------------------------------ ---------------- 220 HybridInitRSA 64221 221 HybridRespRSA 64222 222 HybridInitDSS 64223 223 HybridRespDSS 64224 225 3.3 Notation 227 This document follows the notations defined in [IKE]. 229 4. Description of the Hybrid Authentication Mode 231 The hybrid authentication mode is divided into two stages. The first 232 stage is a Phase 1 Exchange used to authenticate the Edge Device. The 233 exchange follows the same structure and rules as described in [IKE] 234 with some exceptions as described in the following sub-sections. The 235 Phase 1 Exchange can use either Aggressive Mode or Main Mode. The 236 initiator of the Phase 1 Exchange can be either the Client or the 237 Edge Device. The initiator of the following Transaction Exchange MUST 238 be the Edge Device. 240 The Phase 1 Exchange MUST be immediately followed by a Transaction 241 Exchange whose initiator is the Edge Device. The Transaction Exchange 242 MUST be protected by the IKE SA negotiated in the preceding Phase 1 243 Exchange. This IKE SA MUST NOT be used for any other exchange before 244 the Transaction Exchange terminates successfully and the User is 245 authenticated. If the User fails to authenticate the IKE SA MUST be 246 discarded. 248 There are two characteristics that uniquely identify a hybrid 249 authentication method: 251 The first is the direction of the authentication. The latter 252 determines the authentication method used to authenticate the Edge 253 Device (i.e. RSA or DSA). 255 For example, HybridInitRSA denotes Hybrid authentication that 256 utilizes RSA signatures in Phase 1 to authenticate the Edge Device. 257 The initiator of the Phase1 exchange is to be authenticated using 258 XAUTH. 260 4.1 Bidirectional Authentication 262 For a discussion on how to use Bidirectional authentication together 263 with legacy authentication systems see [XAUTH]. 265 4.2 Unidirectional Authentication 267 If the Client's side is not to be authenticated during the Phase 1 268 Exchange, the Phase 1 Exchange is slightly modified in the following 269 manner: 271 The signature payload sent by the Client SIG_I (or SIG_R) is replaced 272 with HASH_I (HASH_R), where HASH_I (HASH_R) contains the hash of the 273 data that would have otherwise be signed in SIG_I (SIG_R). Note 274 however that even if the Edge Device uses a signature scheme tied to 275 a particular hash algorithm (i.e. DSS with SHA), the negotiated prf 276 or the HMAC version of the negotiated hash function MUST be used by 277 the Client when computing HASH_I (HASH_R). 279 If a certificate request payload is sent from the Edge Device the 280 Client MUST respond with an empty certificate payload, i.e. with a 281 certificate payload whose Certificate Data field has zero length. 283 The ID payload sent by the Client SHOULD be left empty (i.e. with an 284 empty Identification Data field and with an ID type of zero) thus 285 providing identity protection for the Client even if Aggressive Mode 286 is used. 288 Examples: 290 Main Mode with hybrid authentication, Client initiator: 291 Initiator Responder 292 ---------- ----------- 293 HDR, SA --> 295 <-- HDR, SA 297 HDR, KE, Ni --> 299 <-- HDR, KE, Nr 301 HDR*, IDii, HASH_I --> 303 <-- HDR*, IDir, [ CERT, ] 304 SIG_R 306 XAUTH-Exchange 308 Aggressive Mode hybrid authentication, Edge Device initiator: 310 Initiator Responder 311 ----------- ----------- 312 HDR, SA, KE, Ni, IDii --> 314 <-- HDR, SA, KE, Nr, IDir, 315 HASH_R 317 HDR, [ CERT, ] SIG_I --> 319 XAUTH-Exchange 321 5. Implementation hints 323 Since the Edge Device always initiates the Transaction Exchange, when 324 a Client initiates the Phase 1 Exchange, the authentication methods 325 included in the Client's proposal should be either HybridInitRSA or 326 HybridInitDSS, whereas if the Edge Device is the initiator of the 327 Phase 1 Exchange the authentication methods included in the Edge 328 Device's proposal should be either HybridRespRSA or HybridRespDSS. 330 6. Security Considerations 331 This document describes a protocol to be used to establish an IKE SA. 332 The level of security the protocol provides, relies among other 333 things, on the strength of the authentication mechanism used to 334 authenticate the Client. 336 While pre-shared key authentication for mobile users can be done only 337 in Aggressive Mode, thus revealing the identity of the User, these 338 proposed methods provide, when used in conjunction with Aggressive 339 Mode, User's identity protection and when used in conjunction with 340 Main Mode, provide identity protection for both parties. 342 While the authors greatly discourage the use of fixed passwords, 343 these methods have another advantage over the pre-shared key method: 344 The password is not prone to offline dictionary attacks, since the 345 password is encrypted using a derivative of the Diffie-Hellman shared 346 key. Only the participants in the IKE protocol know the shared key. 348 NB: When using standard IKE authentication methods both parties can 349 (and must) detect man-in-the-middle attacks. When one uses hybrid 350 authentication to establish unidirectional authenticated IKE SA's, 351 only the Client can (and must) detect these kinds of attacks. 353 This proposal does not provide protection against denial of service 354 attacks in which an attacker, impersonating a User, repeatedly tries 355 to authenticate, eventually causing the User's account to be revoked. 356 Nonetheless, this kind of weakness is inherent to challenge-response 357 techniques and should not be considered a weakness of this protocol 358 but of the authentication methods it utilizes. 360 7. Acknowledgements 362 The authors would like to thank Roy Pereira, Tim Jenkins, Paul 363 Kierstead and Stephen Kent for their comments and contributions to 364 this document. 366 8. References 368 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 369 Requirement Levels", RFC2119 371 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 372 RFC2409 374 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, 375 J., "Internet Security Association and Key Management Protocol 376 (ISAKMP)", RFC2408. 378 [IKECFG] R. Pereira, S. Anand, B. Patel, "The ISAKMP Configuration 379 Method", draft-ietf-ipsec-isakmp-mode-cfg-05.txt 381 [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication Within 382 SAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-06.txt 384 Author Addresses: 386 Moshe Litvin 387 Check Point 388 3A Jabotinsky St. 389 Ramat-Gan 52520 390 ISRAEL 392 Roy Shamir 393 Check Point 394 3A Jabotinsky St. 395 Ramat-Gan 52520 396 ISRAEL 398 Tamir Zegman 399 Check Point 400 3A Jabotinsky St. 401 Ramat-Gan 52520 402 ISRAEL 404 Full Copyright Statement: 406 Copyright (C) The Internet Society (1999). All Rights Reserved. 408 This document and translations of it may be copied and furnished to 409 others, and derivative works that comment on or otherwise explain it 410 or assist in its implementation may be prepared, copied, published 411 and distributed, in whole or in part, without restriction of any 412 kind, provided that the above copyright notice and this paragraph 413 are included on all such copies and derivative works. However, this 414 document itself may not be modified in any way, such as by removing 415 the copyright notice or references to the Internet Society or other 416 Internet organizations, except as needed for the purpose of 417 developing Internet standards in which case the procedures for 418 copyrights defined in the Internet Standards process must be 419 followed, or as required to translate it into languages other than 420 English. 422 The limited permissions granted above are perpetual and will not be 423 revoked by the Internet Society or its successors or assigns. 425 This document and the information contained herein is provided on an 426 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 427 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 428 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 429 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 430 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.