idnits 2.17.1 draft-ietf-ipsec-isakmp-hybrid-auth-01.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 () is 739377 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: 'CFG' is mentioned on line 148, but not defined == Unused Reference: 'ISAKMP' is defined on line 362, 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) == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-isakmp-mode-cfg-04 -- Possible downref: Normative reference to a draft: ref. 'IKECFG' == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-isakmp-xauth-03 -- Possible downref: Normative reference to a draft: ref. 'XAUTH' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group M. Litvin, R. Shamir, T. Zegman 3 INTERNET-DRAFT Check Point Software 4 draft-ietf-ipsec-isakmp-hybrid-auth-01.txt DECEMBER 1998 5 Expires in 6 months 7 A Hybrid Authentication Mode for IKE 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 1. Abstract 30 This document describes a set of new authentication methods to be 31 used within Phase 1 of the Internet Key Exchange (IKE). The proposed 32 methods assume an asymmetry between the authenticating entities. One 33 entity, typically an Edge Device (e.g. firewall), authenticates using 34 standard public key techniques (in signature mode), while the other 35 entity, typically a remote User, authenticates using challenge 36 response techniques. These authentication methods are used to 37 establish, at the end of Phase 1, an IKE SA which is unidirectional 38 authenticated. To make this IKE bi-directional authenticated, this 39 Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The 40 X-Auth Exchange is used to authenticate the remote User. The use of 41 these authentication methods is referred to as Hybrid mode. 43 This proposal is designed to provide a solution for environments 44 where a legacy authentication system exists, yet a full public key 45 infrastructure is not deployed. 47 1.1 Reader Prerequisites 48 It is assumed that the reader is familiar with the terms and concepts 49 described in "Extended Authentication Within ISAKMP/Oakley" [XAUTH] 50 and "The ISAKMP Configuration Method" [IKECFG]. 52 1.2 Changes from previous version 54 The draft was extensively modified since the last version. The most 55 important change is the breaking down of authentication into two 56 stages. The first stage is used to authenticate the Edge Device and 57 is based on Phase 1 Exchange, while the latter authenticates the 58 Client and is based on a Transaction Exchange [IKECFG] with the 59 mechanism described in [XAUTH]. 61 2. Discussion 63 2.1 Background 65 Several authentication methods are currently defined within IKE 66 [IKE]. These methods use either a secret which is shared by the 67 authenticating entities ("pre-shared key" method), or public key 68 cryptography ("digital signature" mode, "public key encryption" mode, 69 "revised public key encryption mode"). Legacy authentication systems, 70 such as Security Dynamics' SecurID and Axent's OmniGuard/Defender, 71 are not addressed in the current standard. 73 Legacy authentication systems are already deployed in many 74 organizations. These organizations may not wish to deploy a public- 75 key infrastructure in the near future. Furthermore, even if an 76 organization decides to deploy a public key infrastructure, the 77 deployment can take a considerable amount of time. Within the 78 transition period, organizations may wish to continue using their 79 legacy authentication systems. 81 2.2 Design considerations 83 The currently defined IKE authentication methods share two 84 properties: the authentication is mutual (both participants in the 85 authenticate each other); and symmetric (both participants use the 86 same method for authentication). Mutual authentication is important 87 not only for mere identification but also to prevent man in the 88 middle attacks. 90 In client-server like implementations of IKE, where one of the 91 participants in the IKE is a User, while the other is an Edge Device 92 (e.g. firewall), it is not always possible to preserve symmetric 93 authentication. For example, a User can use an OmniGuard/Defender 94 token to answer an authentication challenge, but cannot issue an 95 OmniGuard/Defender authentication challenge to the firewall, since 96 she cannot check the firewall's response. 98 When designing an IKE authentication method that addresses legacy 99 authentication systems, it is necessary to preserve the mutual 100 authentication property of IKE, while its symmetric nature may be 101 violated. 103 The authentication methods currently defined in IKE all use a six 104 packet exchange for Main Mode, and a three packet exchange for 105 Aggressive Mode. When defining a new authentication method, which is 106 based on challenge-response authentication, it is not possible to 107 place a limitation on the number of packets that need to be exchanged 108 to authenticate a User. Usually, a simple authentication protocol 109 consists of three messages: a challenge by the Edge Device; a 110 response by the User; and a status message (authentication 111 success/failure) sent by the Edge Device. However, in many cases the 112 protocol consists of more than a single challenge-response (e.g. new 113 PIN mode of SecurID). 115 Due to these limitation, we divide the authentication process into 116 two stages. In the first stage, Phase 1 Exchange is being utilized to 117 authenticate the Edge Device and to establish an IKE SA. In the 118 second stage, a Transaction Exchange [IKECFG] with the mechanism 119 described in [XAUTH] is used to authenticate the Client. Even though 120 the two stages could have been integrated into a single exchange, we 121 feel that this separation, being based on existing exchanges without 122 modifying them, is more easy to implement. 124 In some scenarios, security policy on the Edge Device might call for 125 authentication of both the User and the User's Device. This proposal 126 achieves this goal by using public key authentication to authenticate 127 the User's Device and challenge-response authentication to 128 authenticate the User. 130 This proposal is suitable for environments where a legacy 131 authentication system is deployed, yet public key cryptography can be 132 used by the Edge Devices. In that case, the situation resembles the 133 way authentication is implemented in the World Wide Web using SSL. 134 The servers use public-key techniques to authenticate themselves to 135 the Users, and establish an encrypted connection. The User can then 136 authenticate herself (or send other identification information, such 137 as a credit card number). The assumption in this mode is that 138 deploying public key for a small number of entities (web servers or 139 Edge Devices) is possible without a full-public key infrastructure 140 deployment. 142 2.3 The hybrid authentication mode in a nut-shell 143 The participants in the hybrid authentication mode are typically a 144 User and an Edge Device. The participants start to negotiate, using 145 either Main Mode or Aggressive Mode, an SA in which the 146 authentication method is of a new type, indicating it is a hybrid 147 authentication method. At the end of Phase 1 the established IKE SA 148 is used by the Edge Device to start a Transaction Exchange [CFG] in 149 order to authenticate the User. Upon the successful completion of the 150 exchange the participants can proceed to use the IKE SA for other 151 purposes (e.g. Quick Mode). 153 3. Terms and Definitions 155 3.1 Requirements Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [Bra97]. 161 3.2 Definitions 163 The following terms are used in this document: 165 Edge Device - Gateway, router or firewall protecting a corporate 166 network. 168 User - A person trying to gain access to a corporate network 169 protected by an Edge Device. 171 User's Device - user's device. 173 Client - Denotes both the User and the User's Device. Used whenever a 174 distinction between the two terms is not necessary. 176 3.2.1 Authentication Methods Types 178 The following values relate to hybrid mode authentication. Their use 179 is detailed in following sections. Values are taken from the private 180 use range defined in [IKE] and should be used among mutually 181 consenting parties. 183 Type Value 184 ------------------------------ ---------------- 185 HybridInitOnewayRSA 62221 186 HybridRespOnewayRSA 62222 187 HybridInitMutualRSA 62223 188 HybridRespMutualRSA 62224 189 HybridInitOnewayDSS 62225 190 HybridRespOnewayDSS 62226 191 HybridInitMutualDSS 62227 192 HybridRespMutualDSS 62228 194 3.3 Notation 196 This document follows the notations defined in [IKE]. 198 4. Description of the Hybrid Authentication Mode 200 The hybrid authentication mode is divided into two stages. The first 201 stage is a Phase 1 Exchange used to authenticate the Edge Device (and 202 optionally the User's Device). The exchange follows the same 203 structure and rules as described in [IKE] with some exceptions as 204 described in the following sub-sections. The Phase 1 Exchange can use 205 either Aggressive Mode or Main Mode. The initiator of the Phase 1 206 Exchange can be either the Client or the Edge Device. The initiator 207 of the following Eransaction Exchange MUST be the Edge Device. 209 The Phase 1 Exchange MUST be immediately followed by a Transaction 210 Exchange whose initiator is the Edge Device. The Transaction Exchange 211 MUST be protected by the IKE SA negotiated in the preceding Phase 1 212 Exchange. This IKE SA MUST NOT be used for any other exchange before 213 the Transaction Exchange terminates successfully and the User is 214 authenticated. If the User fails to authenticate the IKE SA MUST be 215 discarded. 217 There are three characteristics that uniquely identify a hybrid 218 authentication method: The authentication method used to authenticate 219 the Edge Device (either RSA signatures or DSS signatures are 220 currently defined); Is the authentication method used in Phase 1 221 supposed to authenticate the User's Device or not; Who should 222 initiate the Transaction Exchange following the Phase 1 Exchange. 223 Thus yielding a total of 8 authentication methods. 225 Examples: 227 HybridInitOnewayRSA denotes Hybrid authentication that utilizes RSA 228 signatures in Phase 1 to authenticate the Edge Device. The initiator 229 of the Transaction Exchange in this case is the initiator of the 230 Phase 1 Exchange. 232 HybridRespMutualDSS denotes Hybrid authentication that utilizes DSS 233 signatures in Phase 1 to authenticate both the Edge Device and the 234 User's Device. The initiator of the Transaction Exchange in this case 235 is the responder of the Phase 1 Exchange. 237 HybridInitMutualRSA denotes Hybrid authentication that utilizes RSA 238 signatures in Phase 1 to authenticate both the Edge Device and the 239 User's Device. The initiator of the Transaction Exchange in this case 240 is the initiator of the Phase 1 Exchange. 242 4.1 Bi-directional Authentication 244 If Hybrid authentication is used to authenticate both the Edge Device 245 and the User's Device (HybridInitMutualRSA, HybridRespMutualRSA, 246 HybridInitMutualDSS, HybridRespMutualDSS) the Phase 1 Exchange is 247 identical to a normal Phase 1 Exchange. 249 The ID payload sent by the Client SHOULD include the identity of the 250 User's Device. 252 4.2 Unidirectional Authentication 254 If the Client's side is not to be authenticated during the Phase 1 255 Exchange, the Phase 1 Exchange is slightly modified in the following 256 manner: 258 The signature payload sent by the Client SIG_I (or SIG_R) is replaced 259 with HASH_I (HASH_R), where HASH_I (HASH_R) contains the hash of the 260 data that would have otherwise be signed in SIG_I (SIG_R). 262 If a certificate request payload is sent from the Edge Device the 263 Client MUST respond with an empty certificate payload, i.e. with a 264 certificate payload whose Certificate Data field has zero length. 266 The ID payload sent by the Client SHOULD be left empty (i.e. with an 267 empty Identification Data field) thus providing identity protection 268 for the Client even if Aggressive Mode is used. 270 Examples: 272 Main Mode with hybrid authentication, Client initiator: 273 Initiator Responder 274 ---------- ----------- 275 HDR, SA --> 277 <-- HDR, SA 279 HDR, KE, Ni --> 281 <-- HDR, KE, Nr 283 HDR*, IDii, HASH_I --> 285 <-- HDR*, IDir, [ CERT, ] 286 SIG_R 288 XAUTH-Exchange 290 Aggressive Mode hybrid authentication, Edge Device initiator: 292 Initiator Responder 293 ----------- ----------- 294 HDR, SA, KE, Ni, IDii --> 296 <-- HDR, SA, KE, Nr, IDir, 297 HASH_R 299 HDR, [ CERT, ] SIG_I --> 301 XAUTH-Exchange 303 5. Implementation hints 305 Since the Edge Device always initiates the Transaction Exchange, when 306 a Client initiates the Phase 1 Exchange, the authentication methods 307 included in the Client's proposal should be taken from the following 308 set: 309 { HybridRespOnewayRSA, HybridRespMutualRSA, 310 HybridRespOnewayDSS, HybridRespMutualDSS } whereas if the Edge 311 Device is the initiator of the Phase 1 Exchange the authentication 312 methods included in the Edge Device's proposal should be taken from 313 the following set: 314 { HybridInitOnewayRSA, HybridInitMutualRSA, 315 HybridInitOnewayDSS, HybridInitMutualDSS } 317 6. Security Considerations 319 This document describes a protocol to be used to establish an IKE SA. 320 The level of security the protocol provides, relies among other 321 things, on the strength of the authentication mechanism used to 322 authenticate the Client. 324 While pre-shared key authentication for mobile users can be done only 325 in Aggressive Mode, thus revealing the identity of the User, these 326 proposed methods provide, when used in conjuction with Aggressive 327 Mode, User's identity protection. When used in conjunction with Main 328 Mode, provide identity protection for both parties. 330 While the authors greatly discourage the use of fixed passwords, 331 these methods have another advantage over the pre-shared key method: 332 The password is not prone to offline dictionary attacks, since the 333 password is encrypted using a derivative of the Diffie-Hellman shared 334 key. Only the participants in the IKE protocol know the shared key. 336 NB: When using standard IKE authentication methods both parties can 337 (and must) detect man-in-the-middle attacks. When one uses hybrid 338 authentication to establish unidirectional authenticated IKE SA's, 339 only the Client can (and must) detect these kinds of attacks. 341 This proposal does not provide protection against denial of service 342 attacks in which an attacker, impersonating a User, repeatedly tries 343 to authenticate, eventually causing the User's account to be revoked. 344 Nonetheless, this kind of weakness is inherent to challenge-response 345 techniques and should not be considered a weakness of this protocol 346 but of the authentication methods it utilizes. 348 7. Acknowledgments 350 The authors would like to thank Roy Pereira, Tim Jenkins Paul 351 Kierstead and Stephen Kent for their comments and contributions to 352 this document. 354 8. References 356 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 357 Requirement Levels", RFC2119 359 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 360 RFC2409 362 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, 363 J., "Internet Security Association and Key Management Protocol 364 (ISAKMP)", RFC2408. 366 [IKECFG] R. Pereira, S. Anand, B. Patel, "The ISAKMP Configuration 367 Method", draft-ietf-ipsec-isakmp-mode-cfg-04.txt 369 [XAUTH] R. Pereira, "Extended Authentication Within SAKMP/Oakley", 370 draft-ietf-ipsec-isakmp-xauth-03.txt 372 Author Addresses: 374 Moshe Litvin 375 Check Point 376 3A Jabotinsky St. 377 Ramat-Gan 52520 378 ISRAEL 380 Roy Shamir 381 Check Point 382 3A Jabotinsky St. 383 Ramat-Gan 52520 384 ISRAEL 386 Tamir Zegman 387 Check Point 388 3A Jabotinsky St. 389 Ramat-Gan 52520 390 ISRAEL