idnits 2.17.1 draft-ietf-ipsec-isakmp-hybrid-auth-04.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 187, but not defined == Unused Reference: 'ISAKMP' is defined on line 378, 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-04.txt July, 2000 4 Expires January, 2001 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.1 Version 4.0 Authentication method numbers were assigned by IANA 70 without altering their values. 72 1.2.2 Version 3.0 74 Draft was renamed and reposted under the IPSRA working group. 76 1.2.3 Version 2.0 78 The authentication methods numbers are now taken from the private use 79 range. 81 Mutual authentication within Phase 1 is now discussed in [XAUTH]. 83 Added clarification on the use of DSS signatures. 85 Added clarification on the content of ID payloads sent by the Client 86 during Phase 1. 88 Changed the semantics of the authentication methods so that they will 89 correspond to similar authentication methods defined in [XAUTH]. 91 1.2.4 Version 1.0 93 The draft was extensively modified since the last version. The most 94 important change is the breaking down of authentication into two 95 stages. The first stage is used to authenticate the Edge Device and 96 is based on Phase 1 Exchange, while the latter authenticates the 97 Client and is based on a Transaction Exchange [IKECFG] with the 98 mechanism described in [XAUTH]. 100 2. Discussion 102 2.1 Background 104 Several authentication methods are currently defined within IKE 105 [IKE]. These methods use either a secret which is shared by the 106 authenticating entities ("pre-shared key" method), or public key 107 cryptography ("digital signature" mode, "public key encryption" mode, 108 "revised public key encryption mode"). Legacy authentication systems, 109 such as Security Dynamics' SecurID and Axent's OmniGuard/Defender, 110 are not addressed in the current standard. 112 Legacy authentication systems are already deployed in many 113 organizations. These organizations may not wish to deploy a public- 114 key infrastructure in the near future. Furthermore, even if an 115 organization decides to deploy a public key infrastructure, the 116 deployment can take a considerable amount of time. Within the 117 transition period, organizations may wish to continue using their 118 legacy authentication systems. 120 2.2 Design considerations 122 The currently defined IKE authentication methods share two 123 properties: the authentication is mutual (both participants 124 authenticate each other); and symmetric (both participants use the 125 same method for authentication). Mutual authentication is important 126 not only for mere identification but also to prevent man in the 127 middle attacks. 129 In client-server like implementations of IKE, where one of the 130 participants in the IKE is a User, while the other is an Edge Device 131 (e.g. firewall), it is not always possible to preserve symmetric 132 authentication. For example, a User can use an OmniGuard/Defender 133 token to answer an authentication challenge, but cannot issue an 134 OmniGuard/Defender authentication challenge to the firewall, since 135 she cannot check the firewall's response. 137 When designing an IKE authentication method that addresses legacy 138 authentication systems, it is necessary to preserve the mutual 139 authentication property of IKE, while its symmetric nature may be 140 violated. 142 The authentication methods currently defined in IKE all use a six 143 packet exchange for Main Mode, and a three packet exchange for 144 Aggressive Mode. When defining a new authentication method, which is 145 based on challenge-response authentication, it is not possible to 146 place a limitation on the number of packets that need to be exchanged 147 to authenticate a User. Usually, a simple authentication protocol 148 consists of three messages: a challenge by the Edge Device; a 149 response by the User; and a status message (authentication 150 success/failure) sent by the Edge Device. However, in many cases the 151 protocol consists of more than a single challenge-response (e.g. new 152 PIN mode of SecurID). 154 Due to these limitation, we divide the authentication process into 155 two stages. In the first stage, Phase 1 Exchange is being utilized to 156 authenticate the Edge Device and to establish an IKE SA. In the 157 second stage, a Transaction Exchange [IKECFG] with the mechanism 158 described in [XAUTH] is used to authenticate the Client. Even though 159 the two stages could have been integrated into a single exchange, we 160 feel that this separation, being based on existing exchanges without 161 modifying them, is easier to implement. 163 This proposal is suitable for environments where a legacy 164 authentication system is deployed, yet public key cryptography can be 165 used by the Edge Devices. In that case, the situation resembles the 166 way authentication is implemented in the World Wide Web using SSL. 167 The servers use public-key techniques to authenticate themselves to 168 the Users, and establish an encrypted connection. The User can then 169 authenticate herself (or send other identification information, such 170 as a credit card number). The assumption in this mode is that 171 deploying public key for a small number of entities (web servers or 172 Edge Devices) is possible without a full-public key infrastructure 173 deployment. 175 In some scenarios, security policy on the Edge Device might call for 176 authentication of both the User and the User's Device. In such a case 177 the Phase 1 authentication methods described in [XAUTH] should be 178 used. 180 2.3 The hybrid authentication mode in a nut-shell 182 The participants in the hybrid authentication mode are typically a 183 User and an Edge Device. The participants start to negotiate, using 184 either Main Mode or Aggressive Mode, an SA in which the 185 authentication method is of a new type, indicating it is a hybrid 186 authentication method. At the end of Phase 1 the established IKE SA 187 is used by the Edge Device to start a Transaction Exchange [CFG] in 188 order to authenticate the User. Upon the successful completion of the 189 exchange the participants can proceed to use the IKE SA for other 190 purposes (e.g. Quick Mode). 192 3. Terms and Definitions 194 3.1 Requirements Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [Bra97]. 200 3.2 Definitions 202 The following terms are used in this document: 204 Edge Device - Gateway, router or firewall protecting a corporate 205 network. 207 User - A person trying to gain access to a corporate network 208 protected by an Edge Device. 210 User's Device - user's device. 212 Client - Denotes both the User and the User's Device. Used whenever a 213 distinction between the two terms is not necessary. 215 3.2.1 Authentication Methods Types 217 The following values relate to hybrid mode authentication. Their use 218 is detailed in following sections. These values were assigned by 219 IANA. 221 Type Value 222 ------------------------------ ---------------- 223 HybridInitRSA 64221 224 HybridRespRSA 64222 225 HybridInitDSS 64223 226 HybridRespDSS 64224 228 3.3 Notation 230 This document follows the notations defined in [IKE]. 232 4. Description of the Hybrid Authentication Mode 234 The hybrid authentication mode is divided into two stages. The first 235 stage is a Phase 1 Exchange used to authenticate the Edge Device. The 236 exchange follows the same structure and rules as described in [IKE] 237 with some exceptions as described in the following sub-sections. The 238 Phase 1 Exchange can use either Aggressive Mode or Main Mode. The 239 initiator of the Phase 1 Exchange can be either the Client or the 240 Edge Device. The initiator of the following Transaction Exchange MUST 241 be the Edge Device. 243 The Phase 1 Exchange MUST be immediately followed by a Transaction 244 Exchange whose initiator is the Edge Device. The Transaction Exchange 245 MUST be protected by the IKE SA negotiated in the preceding Phase 1 246 Exchange. This IKE SA MUST NOT be used for any other exchange before 247 the Transaction Exchange terminates successfully and the User is 248 authenticated. If the User fails to authenticate the IKE SA MUST be 249 discarded. 251 There are two characteristics that uniquely identify a hybrid 252 authentication method: 254 The first is the direction of the authentication. The latter 255 determines the authentication method used to authenticate the Edge 256 Device (i.e. RSA or DSA). 258 For example, HybridInitRSA denotes Hybrid authentication that 259 utilizes RSA signatures in Phase 1 to authenticate the Edge Device. 260 The initiator of the Phase1 exchange is to be authenticated using 261 XAUTH. 263 4.1 Bidirectional Authentication 265 For a discussion on how to use Bidirectional authentication together 266 with legacy authentication systems see [XAUTH]. 268 4.2 Unidirectional Authentication 270 If the Client's side is not to be authenticated during the Phase 1 271 Exchange, the Phase 1 Exchange is slightly modified in the following 272 manner: 274 The signature payload sent by the Client SIG_I (or SIG_R) is replaced 275 with HASH_I (HASH_R), where HASH_I (HASH_R) contains the hash of the 276 data that would have otherwise be signed in SIG_I (SIG_R). Note 277 however that even if the Edge Device uses a signature scheme tied to 278 a particular hash algorithm (i.e. DSS with SHA), the negotiated prf 279 or the HMAC version of the negotiated hash function MUST be used by 280 the Client when computing HASH_I (HASH_R). 282 If a certificate request payload is sent from the Edge Device the 283 Client MUST respond with an empty certificate payload, i.e. with a 284 certificate payload whose Certificate Data field has zero length. 286 The ID payload sent by the Client SHOULD be left empty (i.e. with an 287 empty Identification Data field and with an ID type of zero) thus 288 providing identity protection for the Client even if Aggressive Mode 289 is used. 291 Examples: 293 Main Mode with hybrid authentication, Client initiator: 294 Initiator Responder 295 ---------- ----------- 296 HDR, SA --> 298 <-- HDR, SA 300 HDR, KE, Ni --> 302 <-- HDR, KE, Nr 304 HDR*, IDii, HASH_I --> 306 <-- HDR*, IDir, [ CERT, ] 307 SIG_R 309 XAUTH-Exchange 311 Aggressive Mode hybrid authentication, Edge Device initiator: 313 Initiator Responder 314 ----------- ----------- 315 HDR, SA, KE, Ni, IDii --> 317 <-- HDR, SA, KE, Nr, IDir, 318 HASH_R 320 HDR, [ CERT, ] SIG_I --> 322 XAUTH-Exchange 324 5. Implementation hints 326 Since the Edge Device always initiates the Transaction Exchange, when 327 a Client initiates the Phase 1 Exchange, the authentication methods 328 included in the Client's proposal should be either HybridInitRSA or 329 HybridInitDSS, whereas if the Edge Device is the initiator of the 330 Phase 1 Exchange the authentication methods included in the Edge 331 Device's proposal should be either HybridRespRSA or HybridRespDSS. 333 6. Security Considerations 335 This document describes a protocol to be used to establish an IKE SA. 336 The level of security the protocol provides, relies among other 337 things, on the strength of the authentication mechanism used to 338 authenticate the Client. 340 While pre-shared key authentication for mobile users can be done only 341 in Aggressive Mode, thus revealing the identity of the User, these 342 proposed methods provide, when used in conjunction with Aggressive 343 Mode, User's identity protection and when used in conjunction with 344 Main Mode, provide identity protection for both parties. 346 While the authors greatly discourage the use of fixed passwords, 347 these methods have another advantage over the pre-shared key method: 348 The password is not prone to offline dictionary attacks, since the 349 password is encrypted using a derivative of the Diffie-Hellman shared 350 key. Only the participants in the IKE protocol know the shared key. 352 NB: When using standard IKE authentication methods both parties can 353 (and must) detect man-in-the-middle attacks. When one uses hybrid 354 authentication to establish unidirectional authenticated IKE SA's, 355 only the Client can (and must) detect these kinds of attacks. 357 This proposal does not provide protection against denial of service 358 attacks in which an attacker, impersonating a User, repeatedly tries 359 to authenticate, eventually causing the User's account to be revoked. 360 Nonetheless, this kind of weakness is inherent to challenge-response 361 techniques and should not be considered a weakness of this protocol 362 but of the authentication methods it utilizes. 364 7. Acknowledgements 366 The authors would like to thank Roy Pereira, Tim Jenkins, Paul 367 Kierstead and Stephen Kent for their comments and contributions to 368 this document. 370 8. References 372 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 373 Requirement Levels", RFC2119 375 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 376 RFC2409 378 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, 379 J., "Internet Security Association and Key Management Protocol 380 (ISAKMP)", RFC2408. 382 [IKECFG] R. Pereira, S. Anand, B. Patel, "The ISAKMP Configuration 383 Method", draft-ietf-ipsec-isakmp-mode-cfg-05.txt 385 [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication Within 386 ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-06.txt 388 Author Addresses: 390 Moshe Litvin 391 Check Point 392 3A Jabotinsky St. 393 Ramat-Gan 52520 394 ISRAEL 396 Roy Shamir 397 Check Point 398 3A Jabotinsky St. 399 Ramat-Gan 52520 400 ISRAEL 402 Tamir Zegman 403 Check Point 404 3A Jabotinsky St. 405 Ramat-Gan 52520 406 ISRAEL 408 Full Copyright Statement: 410 Copyright (C) The Internet Society (2000). All Rights Reserved. 412 This document and translations of it may be copied and furnished to 413 others, and derivative works that comment on or otherwise explain it 414 or assist in its implementation may be prepared, copied, published 415 and distributed, in whole or in part, without restriction of any 416 kind, provided that the above copyright notice and this paragraph 417 are included on all such copies and derivative works. However, this 418 document itself may not be modified in any way, such as by removing 419 the copyright notice or references to the Internet Society or other 420 Internet organizations, except as needed for the purpose of 421 developing Internet standards in which case the procedures for 422 copyrights defined in the Internet Standards process must be 423 followed, or as required to translate it into languages other than 424 English. 426 The limited permissions granted above are perpetual and will not be 427 revoked by the Internet Society or its successors or assigns. 429 This document and the information contained herein is provided on an 430 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 431 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 432 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 433 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 434 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.