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