IPSEC Working Group M. Litvin, R. Shamir, T. Zegman INTERNET-DRAFT Check Point Software draft-ietf-ipsec-isakmp-hybrid-auth-01.txt DECEMBER 1998 Expires in 6 months A Hybrid Authentication Mode for IKE Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectional authenticated. To make this IKE bi-directional authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. 1.1 Reader Prerequisites Litvin, Shamir, Zegman [Page 1] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 It is assumed that the reader is familiar with the terms and concepts described in "Extended Authentication Within ISAKMP/Oakley" [XAUTH] and "The ISAKMP Configuration Method" [IKECFG]. 1.2 Changes from previous version The draft was extensively modified since the last version. The most important change is the breaking down of authentication into two stages. The first stage is used to authenticate the Edge Device and is based on Phase 1 Exchange, while the latter authenticates the Client and is based on a Transaction Exchange [IKECFG] with the mechanism described in [XAUTH]. 2. Discussion 2.1 Background Several authentication methods are currently defined within IKE [IKE]. These methods use either a secret which is shared by the authenticating entities ("pre-shared key" method), or public key cryptography ("digital signature" mode, "public key encryption" mode, "revised public key encryption mode"). Legacy authentication systems, such as Security Dynamics' SecurID and Axent's OmniGuard/Defender, are not addressed in the current standard. Legacy authentication systems are already deployed in many organizations. These organizations may not wish to deploy a public- key infrastructure in the near future. Furthermore, even if an organization decides to deploy a public key infrastructure, the deployment can take a considerable amount of time. Within the transition period, organizations may wish to continue using their legacy authentication systems. 2.2 Design considerations The currently defined IKE authentication methods share two properties: the authentication is mutual (both participants in the authenticate each other); and symmetric (both participants use the same method for authentication). Mutual authentication is important not only for mere identification but also to prevent man in the middle attacks. In client-server like implementations of IKE, where one of the participants in the IKE is a User, while the other is an Edge Device (e.g. firewall), it is not always possible to preserve symmetric authentication. For example, a User can use an OmniGuard/Defender token to answer an authentication challenge, but cannot issue an OmniGuard/Defender authentication challenge to the firewall, since Litvin, Shamir, Zegman [Page 2] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 she cannot check the firewall's response. When designing an IKE authentication method that addresses legacy authentication systems, it is necessary to preserve the mutual authentication property of IKE, while its symmetric nature may be violated. The authentication methods currently defined in IKE all use a six packet exchange for Main Mode, and a three packet exchange for Aggressive Mode. When defining a new authentication method, which is based on challenge-response authentication, it is not possible to place a limitation on the number of packets that need to be exchanged to authenticate a User. Usually, a simple authentication protocol consists of three messages: a challenge by the Edge Device; a response by the User; and a status message (authentication success/failure) sent by the Edge Device. However, in many cases the protocol consists of more than a single challenge-response (e.g. new PIN mode of SecurID). Due to these limitation, we divide the authentication process into two stages. In the first stage, Phase 1 Exchange is being utilized to authenticate the Edge Device and to establish an IKE SA. In the second stage, a Transaction Exchange [IKECFG] with the mechanism described in [XAUTH] is used to authenticate the Client. Even though the two stages could have been integrated into a single exchange, we feel that this separation, being based on existing exchanges without modifying them, is more easy to implement. In some scenarios, security policy on the Edge Device might call for authentication of both the User and the User's Device. This proposal achieves this goal by using public key authentication to authenticate the User's Device and challenge-response authentication to authenticate the User. This proposal is suitable for environments where a legacy authentication system is deployed, yet public key cryptography can be used by the Edge Devices. In that case, the situation resembles the way authentication is implemented in the World Wide Web using SSL. The servers use public-key techniques to authenticate themselves to the Users, and establish an encrypted connection. The User can then authenticate herself (or send other identification information, such as a credit card number). The assumption in this mode is that deploying public key for a small number of entities (web servers or Edge Devices) is possible without a full-public key infrastructure deployment. 2.3 The hybrid authentication mode in a nut-shell Litvin, Shamir, Zegman [Page 3] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 The participants in the hybrid authentication mode are typically a User and an Edge Device. The participants start to negotiate, using either Main Mode or Aggressive Mode, an SA in which the authentication method is of a new type, indicating it is a hybrid authentication method. At the end of Phase 1 the established IKE SA is used by the Edge Device to start a Transaction Exchange [CFG] in order to authenticate the User. Upon the successful completion of the exchange the participants can proceed to use the IKE SA for other purposes (e.g. Quick Mode). 3. Terms and Definitions 3.1 Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97]. 3.2 Definitions The following terms are used in this document: Edge Device - Gateway, router or firewall protecting a corporate network. User - A person trying to gain access to a corporate network protected by an Edge Device. User's Device - user's device. Client - Denotes both the User and the User's Device. Used whenever a distinction between the two terms is not necessary. 3.2.1 Authentication Methods Types The following values relate to hybrid mode authentication. Their use is detailed in following sections. Values are taken from the private use range defined in [IKE] and should be used among mutually consenting parties. Type Value ------------------------------ ---------------- HybridInitOnewayRSA 62221 HybridRespOnewayRSA 62222 HybridInitMutualRSA 62223 HybridRespMutualRSA 62224 HybridInitOnewayDSS 62225 HybridRespOnewayDSS 62226 Litvin, Shamir, Zegman [Page 4] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 HybridInitMutualDSS 62227 HybridRespMutualDSS 62228 3.3 Notation This document follows the notations defined in [IKE]. 4. Description of the Hybrid Authentication Mode The hybrid authentication mode is divided into two stages. The first stage is a Phase 1 Exchange used to authenticate the Edge Device (and optionally the User's Device). The exchange follows the same structure and rules as described in [IKE] with some exceptions as described in the following sub-sections. The Phase 1 Exchange can use either Aggressive Mode or Main Mode. The initiator of the Phase 1 Exchange can be either the Client or the Edge Device. The initiator of the following Eransaction Exchange MUST be the Edge Device. The Phase 1 Exchange MUST be immediately followed by a Transaction Exchange whose initiator is the Edge Device. The Transaction Exchange MUST be protected by the IKE SA negotiated in the preceding Phase 1 Exchange. This IKE SA MUST NOT be used for any other exchange before the Transaction Exchange terminates successfully and the User is authenticated. If the User fails to authenticate the IKE SA MUST be discarded. There are three characteristics that uniquely identify a hybrid authentication method: The authentication method used to authenticate the Edge Device (either RSA signatures or DSS signatures are currently defined); Is the authentication method used in Phase 1 supposed to authenticate the User's Device or not; Who should initiate the Transaction Exchange following the Phase 1 Exchange. Thus yielding a total of 8 authentication methods. Examples: HybridInitOnewayRSA denotes Hybrid authentication that utilizes RSA signatures in Phase 1 to authenticate the Edge Device. The initiator of the Transaction Exchange in this case is the initiator of the Phase 1 Exchange. HybridRespMutualDSS denotes Hybrid authentication that utilizes DSS signatures in Phase 1 to authenticate both the Edge Device and the User's Device. The initiator of the Transaction Exchange in this case is the responder of the Phase 1 Exchange. HybridInitMutualRSA denotes Hybrid authentication that utilizes RSA Litvin, Shamir, Zegman [Page 5] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 signatures in Phase 1 to authenticate both the Edge Device and the User's Device. The initiator of the Transaction Exchange in this case is the initiator of the Phase 1 Exchange. 4.1 Bi-directional Authentication If Hybrid authentication is used to authenticate both the Edge Device and the User's Device (HybridInitMutualRSA, HybridRespMutualRSA, HybridInitMutualDSS, HybridRespMutualDSS) the Phase 1 Exchange is identical to a normal Phase 1 Exchange. The ID payload sent by the Client SHOULD include the identity of the User's Device. 4.2 Unidirectional Authentication If the Client's side is not to be authenticated during the Phase 1 Exchange, the Phase 1 Exchange is slightly modified in the following manner: The signature payload sent by the Client SIG_I (or SIG_R) is replaced with HASH_I (HASH_R), where HASH_I (HASH_R) contains the hash of the data that would have otherwise be signed in SIG_I (SIG_R). If a certificate request payload is sent from the Edge Device the Client MUST respond with an empty certificate payload, i.e. with a certificate payload whose Certificate Data field has zero length. The ID payload sent by the Client SHOULD be left empty (i.e. with an empty Identification Data field) thus providing identity protection for the Client even if Aggressive Mode is used. Examples: Main Mode with hybrid authentication, Client initiator: Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, [ CERT, ] Litvin, Shamir, Zegman [Page 6] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 SIG_R XAUTH-Exchange Aggressive Mode hybrid authentication, Edge Device initiator: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, [ CERT, ] SIG_I --> XAUTH-Exchange 5. Implementation hints Since the Edge Device always initiates the Transaction Exchange, when a Client initiates the Phase 1 Exchange, the authentication methods included in the Client's proposal should be taken from the following set: { HybridRespOnewayRSA, HybridRespMutualRSA, HybridRespOnewayDSS, HybridRespMutualDSS } whereas if the Edge Device is the initiator of the Phase 1 Exchange the authentication methods included in the Edge Device's proposal should be taken from the following set: { HybridInitOnewayRSA, HybridInitMutualRSA, HybridInitOnewayDSS, HybridInitMutualDSS } 6. Security Considerations This document describes a protocol to be used to establish an IKE SA. The level of security the protocol provides, relies among other things, on the strength of the authentication mechanism used to authenticate the Client. While pre-shared key authentication for mobile users can be done only in Aggressive Mode, thus revealing the identity of the User, these proposed methods provide, when used in conjuction with Aggressive Mode, User's identity protection. When used in conjunction with Main Mode, provide identity protection for both parties. While the authors greatly discourage the use of fixed passwords, these methods have another advantage over the pre-shared key method: The password is not prone to offline dictionary attacks, since the password is encrypted using a derivative of the Diffie-Hellman shared Litvin, Shamir, Zegman [Page 7] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 key. Only the participants in the IKE protocol know the shared key. NB: When using standard IKE authentication methods both parties can (and must) detect man-in-the-middle attacks. When one uses hybrid authentication to establish unidirectional authenticated IKE SA's, only the Client can (and must) detect these kinds of attacks. This proposal does not provide protection against denial of service attacks in which an attacker, impersonating a User, repeatedly tries to authenticate, eventually causing the User's account to be revoked. Nonetheless, this kind of weakness is inherent to challenge-response techniques and should not be considered a weakness of this protocol but of the authentication methods it utilizes. 7. Acknowledgments The authors would like to thank Roy Pereira, Tim Jenkins Paul Kierstead and Stephen Kent for their comments and contributions to this document. Litvin, Shamir, Zegman [Page 8] INTERNET DRAFT A Hybrid Authentication Mode for IKE DECEMBER 1998 8. References [Bra97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC2409 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC2408. [IKECFG] R. Pereira, S. Anand, B. Patel, "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-mode-cfg-04.txt [XAUTH] R. Pereira, "Extended Authentication Within SAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-03.txt Author Addresses: Moshe Litvin Check Point 3A Jabotinsky St. Ramat-Gan 52520 ISRAEL Roy Shamir Check Point 3A Jabotinsky St. Ramat-Gan 52520 ISRAEL Tamir Zegman Check Point 3A Jabotinsky St. Ramat-Gan 52520 ISRAEL Litvin, Shamir, Zegman [Page 9]