idnits 2.17.1 draft-ietf-ipsec-isakmp-hybrid-auth-05.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. 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CFG' is mentioned on line 191, but not defined == Unused Reference: 'ISAKMP' is defined on line 381, 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) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Litvin, R. Shamir, T. Zegman 3 Expires February, 2001 Check Point Software 4 Category: Informational August, 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 an Internet-Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet-Drafts draft documents are valid for a maximum of six months 20 and may be updated, replaced, or made obsolete by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 1. Abstract 38 This document describes a set of new authentication methods to be 39 used within Phase 1 of the Internet Key Exchange (IKE). The proposed 40 methods assume an asymmetry between the authenticating entities. One 41 entity, typically an Edge Device (e.g. firewall), authenticates using 42 standard public key techniques (in signature mode), while the other 43 entity, typically a remote User, authenticates using challenge 44 response techniques. These authentication methods are used to 45 establish, at the end of Phase 1, an IKE SA which is unidirectionally 46 authenticated. To make this IKE bi-directionally authenticated, this 47 Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The 48 X-Auth Exchange is used to authenticate the remote User. The use of 49 these authentication methods is referred to as Hybrid Authentication 50 mode. 52 This proposal is designed to provide a solution for environments 53 where a legacy authentication system exists, yet a full public key 54 infrastructure is not deployed. 56 1.1 Reader Prerequisites 58 It is assumed that the reader is familiar with the terms and concepts 59 described in "Extended Authentication Within ISAKMP/Oakley" [XAUTH] 60 and "The ISAKMP Configuration Method" [IKECFG]. 62 1.2 Changes from previous version 64 1.2.1 Version 5.0 66 The document has undergone minor modification to prepare for for 67 independent submission as an Informational RFC. 69 Authentication method numbers are yet to be assigned by IANA. 71 1.2.2 Version 4.0 73 Authentication method numbers were assigned by IANA without altering 74 their values. 76 1.2.3 Version 3.0 78 Draft was renamed and reposted under the IPSRA working group. 80 1.2.4 Version 2.0 82 The authentication methods numbers are now taken from the private use 83 range. 85 Mutual authentication within Phase 1 is now discussed in [XAUTH]. 87 Added clarification on the use of DSS signatures. 89 Added clarification on the content of ID payloads sent by the Client 90 during Phase 1. 92 Changed the semantics of the authentication methods so that they will 93 correspond to similar authentication methods defined in [XAUTH]. 95 1.2.5 Version 1.0 97 The draft was extensively modified since the last version. The most 98 important change is the breaking down of authentication into two 99 stages. The first stage is used to authenticate the Edge Device and 100 is based on Phase 1 Exchange, while the latter authenticates the 101 Client and is based on a Transaction Exchange [IKECFG] with the 102 mechanism described in [XAUTH]. 104 2. Discussion 106 2.1 Background 108 Several authentication methods are currently defined within IKE 109 [IKE]. These methods use either a secret which is shared by the 110 authenticating entities ("pre-shared key" method), or public key 111 cryptography ("digital signature" mode, "public key encryption" mode, 112 "revised public key encryption mode"). Legacy authentication systems, 113 such as Security Dynamics' SecurID and Axent's OmniGuard/Defender, 114 are not addressed in the current standard. 116 Legacy authentication systems are already deployed in many 117 organizations. These organizations may not wish to deploy a public- 118 key infrastructure in the near future. Furthermore, even if an 119 organization decides to deploy a public key infrastructure, the 120 deployment can take a considerable amount of time. Within the 121 transition period, organizations may wish to continue using their 122 legacy authentication systems. 124 2.2 Design considerations 126 The currently defined IKE authentication methods share two 127 properties: the authentication is mutual (both participants 128 authenticate each other); and symmetric (both participants use the 129 same method for authentication). Mutual authentication is important 130 not only for mere identification but also to prevent man in the 131 middle attacks. 133 In client-server like implementations of IKE, where one of the 134 participants in the IKE is a User, while the other is an Edge Device 135 (e.g. firewall), it is not always possible to preserve symmetric 136 authentication. For example, a User can use an OmniGuard/Defender 137 token to answer an authentication challenge, but cannot issue an 138 OmniGuard/Defender authentication challenge to the firewall, since 139 she cannot check the firewall's response. 141 When designing an IKE authentication method that addresses legacy 142 authentication systems, it is necessary to preserve the mutual 143 authentication property of IKE, while its symmetric nature may be 144 violated. 146 The authentication methods currently defined in IKE all use a six 147 packet exchange for Main Mode, and a three packet exchange for 148 Aggressive Mode. When defining a new authentication method, which is 149 based on challenge-response authentication, it is not possible to 150 place a limitation on the number of packets that need to be exchanged 151 to authenticate a User. Usually, a simple authentication protocol 152 consists of three messages: a challenge by the Edge Device; a 153 response by the User; and a status message (authentication 154 success/failure) sent by the Edge Device. However, in many cases the 155 protocol consists of more than a single challenge-response (e.g. new 156 PIN mode of SecurID). 158 Due to these limitation, we divide the authentication process into 159 two stages. In the first stage, Phase 1 Exchange is being utilized to 160 authenticate the Edge Device and to establish an IKE SA. In the 161 second stage, a Transaction Exchange [IKECFG] with the mechanism 162 described in [XAUTH] is used to authenticate the Client. Even though 163 the two stages could have been integrated into a single exchange, we 164 feel that this separation, being based on existing exchanges without 165 modifying them, is easier to implement. 167 This proposal is suitable for environments where a legacy 168 authentication system is deployed, yet public key cryptography can be 169 used by the Edge Devices. In that case, the situation resembles the 170 way authentication is implemented in the World Wide Web using SSL. 171 The servers use public-key techniques to authenticate themselves to 172 the Users, and establish an encrypted connection. The User can then 173 authenticate herself (or send other identification information, such 174 as a credit card number). The assumption in this mode is that 175 deploying public key for a small number of entities (web servers or 176 Edge Devices) is possible without a full-public key infrastructure 177 deployment. 179 In some scenarios, security policy on the Edge Device might call for 180 authentication of both the User and the User's Device. In such a case 181 the Phase 1 authentication methods described in [XAUTH] should be 182 used. 184 2.3 The hybrid authentication mode in a nut-shell 186 The participants in the hybrid authentication mode are typically a 187 User and an Edge Device. The participants start to negotiate, using 188 either Main Mode or Aggressive Mode, an SA in which the 189 authentication method is of a new type, indicating it is a hybrid 190 authentication method. At the end of Phase 1 the established IKE SA 191 is used by the Edge Device to start a Transaction Exchange [CFG] in 192 order to authenticate the User. Upon the successful completion of the 193 exchange the participants can proceed to use the IKE SA for other 194 purposes (e.g. Quick Mode). 196 3. Terms and Definitions 198 3.1 Requirements Terminology 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [Bra97]. 204 3.2 Definitions 206 The following terms are used in this document: 208 Edge Device - Gateway, router or firewall protecting a corporate 209 network. 211 User - A person trying to gain access to a corporate network 212 protected by an Edge Device. 214 User's Device - user's device. 216 Client - Denotes both the User and the User's Device. Used whenever a 217 distinction between the two terms is not necessary. 219 3.2.1 Authentication Methods Types 221 The following values relate to hybrid mode authentication. Their use 222 is detailed in following sections. These values are pending 223 assignment by IANA. 225 Type Value 226 ------------------------------ ---------------- 227 HybridInitRSA 64221 228 HybridRespRSA 64222 229 HybridInitDSS 64223 230 HybridRespDSS 64224 232 3.3 Notation 234 This document follows the notations defined in [IKE]. 236 4. Description of the Hybrid Authentication Mode 237 The hybrid authentication mode is divided into two stages. The first 238 stage is a Phase 1 Exchange used to authenticate the Edge Device. The 239 exchange follows the same structure and rules as described in [IKE] 240 with some exceptions as described in the following sub-sections. The 241 Phase 1 Exchange can use either Aggressive Mode or Main Mode. The 242 initiator of the Phase 1 Exchange can be either the Client or the 243 Edge Device. The initiator of the following Transaction Exchange MUST 244 be the Edge Device. 246 The Phase 1 Exchange MUST be immediately followed by a Transaction 247 Exchange whose initiator is the Edge Device. The Transaction Exchange 248 MUST be protected by the IKE SA negotiated in the preceding Phase 1 249 Exchange. This IKE SA MUST NOT be used for any other exchange before 250 the Transaction Exchange terminates successfully and the User is 251 authenticated. If the User fails to authenticate the IKE SA MUST be 252 discarded. 254 There are two characteristics that uniquely identify a hybrid 255 authentication method: 257 The first is the direction of the authentication. The latter 258 determines the authentication method used to authenticate the Edge 259 Device (i.e. RSA or DSA). 261 For example, HybridInitRSA denotes Hybrid authentication that 262 utilizes RSA signatures in Phase 1 to authenticate the Edge Device. 263 The initiator of the Phase1 exchange is to be authenticated using 264 XAUTH. 266 4.1 Bidirectional Authentication 268 For a discussion on how to use Bidirectional authentication together 269 with legacy authentication systems see [XAUTH]. 271 4.2 Unidirectional Authentication 273 If the Client's side is not to be authenticated during the Phase 1 274 Exchange, the Phase 1 Exchange is slightly modified in the following 275 manner: 277 The signature payload sent by the Client SIG_I (or SIG_R) is replaced 278 with HASH_I (HASH_R), where HASH_I (HASH_R) contains the hash of the 279 data that would have otherwise be signed in SIG_I (SIG_R). Note 280 however that even if the Edge Device uses a signature scheme tied to 281 a particular hash algorithm (i.e. DSS with SHA), the negotiated prf 282 or the HMAC version of the negotiated hash function MUST be used by 283 the Client when computing HASH_I (HASH_R). 285 If a certificate request payload is sent from the Edge Device the 286 Client MUST respond with an empty certificate payload, i.e. with a 287 certificate payload whose Certificate Data field has zero length. 289 The ID payload sent by the Client SHOULD be left empty (i.e. with an 290 empty Identification Data field and with an ID type of zero) thus 291 providing identity protection for the Client even if Aggressive Mode 292 is used. 294 Examples: 296 Main Mode with hybrid authentication, Client initiator: 297 Initiator Responder 298 ---------- ----------- 299 HDR, SA --> 301 <-- HDR, SA 303 HDR, KE, Ni --> 305 <-- HDR, KE, Nr 307 HDR*, IDii, HASH_I --> 309 <-- HDR*, IDir, [ CERT, ] 310 SIG_R 312 XAUTH-Exchange 314 Aggressive Mode hybrid authentication, Edge Device initiator: 316 Initiator Responder 317 ----------- ----------- 318 HDR, SA, KE, Ni, IDii --> 320 <-- HDR, SA, KE, Nr, IDir, 321 HASH_R 323 HDR, [ CERT, ] SIG_I --> 325 XAUTH-Exchange 327 5. Implementation hints 329 Since the Edge Device always initiates the Transaction Exchange, when 330 a Client initiates the Phase 1 Exchange, the authentication methods 331 included in the Client's proposal should be either HybridInitRSA or 332 HybridInitDSS, whereas if the Edge Device is the initiator of the 333 Phase 1 Exchange the authentication methods included in the Edge 334 Device's proposal should be either HybridRespRSA or HybridRespDSS. 336 6. Security Considerations 338 This document describes a protocol to be used to establish an IKE SA. 339 The level of security the protocol provides, relies among other 340 things, on the strength of the authentication mechanism used to 341 authenticate the Client. 343 While pre-shared key authentication for mobile users can be done only 344 in Aggressive Mode, thus revealing the identity of the User, these 345 proposed methods provide, when used in conjunction with Aggressive 346 Mode, User's identity protection and when used in conjunction with 347 Main Mode, provide identity protection for both parties. 349 While the authors greatly discourage the use of fixed passwords, 350 these methods have another advantage over the pre-shared key method: 351 The password is not prone to offline dictionary attacks, since the 352 password is encrypted using a derivative of the Diffie-Hellman shared 353 key. Only the participants in the IKE protocol know the shared key. 355 NB: When using standard IKE authentication methods both parties can 356 (and must) detect man-in-the-middle attacks. When one uses hybrid 357 authentication to establish unidirectional authenticated IKE SA's, 358 only the Client can (and must) detect these kinds of attacks. 360 This proposal does not provide protection against denial of service 361 attacks in which an attacker, impersonating a User, repeatedly tries 362 to authenticate, eventually causing the User's account to be revoked. 363 Nonetheless, this kind of weakness is inherent to challenge-response 364 techniques and should not be considered a weakness of this protocol 365 but of the authentication methods it utilizes. 367 7. Acknowledgements 369 The authors would like to thank Roy Pereira, Tim Jenkins, Paul 370 Kierstead and Stephen Kent for their comments and contributions to 371 this document. 373 8. References 375 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 376 Requirement Levels", RFC2119 378 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 379 RFC2409 381 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, 382 J., "Internet Security Association and Key Management Protocol 383 (ISAKMP)", RFC2408. 385 [IKECFG] R. Pereira, S. Anand, B. Patel, "The ISAKMP Configuration 386 Method", draft-ietf-ipsec-isakmp-mode-cfg-05.txt, work in progress. 388 [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication Within 389 ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-06.txt, work in 390 progress. 392 Author Addresses: 394 Moshe Litvin 395 Check Point 396 3A Jabotinsky St. 397 Ramat-Gan 52520 398 ISRAEL 400 Roy Shamir 401 Check Point 402 3A Jabotinsky St. 403 Ramat-Gan 52520 404 ISRAEL 406 Tamir Zegman 407 Check Point 408 3A Jabotinsky St. 409 Ramat-Gan 52520 410 ISRAEL 412 Full Copyright Statement: 414 Copyright (C) The Internet Society (2000). All Rights Reserved. 416 This document and translations of it may be copied and furnished to 417 others, and derivative works that comment on or otherwise explain it 418 or assist in its implementation may be prepared, copied, published 419 and distributed, in whole or in part, without restriction of any 420 kind, provided that the above copyright notice and this paragraph 421 are included on all such copies and derivative works. However, this 422 document itself may not be modified in any way, such as by removing 423 the copyright notice or references to the Internet Society or other 424 Internet organizations, except as needed for the purpose of 425 developing Internet standards in which case the procedures for 426 copyrights defined in the Internet Standards process must be 427 followed, or as required to translate it into languages other than 428 English. 430 The limited permissions granted above are perpetual and will not be 431 revoked by the Internet Society or its successors or assigns. 433 This document and the information contained herein is provided on an 434 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 435 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 436 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 437 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 438 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.