IPSEC Working Group M. Litvin, R. Shamir INTERNET-DRAFT Check Point Software draft-litvin-ipsec-isakmp-hybrid-auth-00.txt June 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 new authentication mode for the Internet Key Exchange (IKE). This mode extends the authentication modes defined in [IKE]. The proposed mode assumes an asymmetry between the authenticating entities. One entity, typically an edge device (e.g. firewall), authenticates using public key techniques, while the other entity, typically a remote user, authenticates using challenge response techniques. The mode is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. 2. Discussion 2.1 Background Four authentication modes are currently defined within IKE [IKE]. These modes use either a secret which is shared by the authenticating entities ("pre-shared secret" mode), or public key cryptography ("digital signature" mode, "public key encryption" mode, and "revised Litvin, Shamir [Page 1] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 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 modes share two properties: the authentication is mutual (both participants in the IKE authenticate each other); and symmetric (both use the same method for authentication). Mutual authentication is important not only for mere authentication 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 she cannot check the response. When designing an IKE authentication mode that addresses legacy authentication systems, it is necessary to preserve the mutual authentication property of IKE, while its symmetric nature may be violated. In the suggested hybrid mode, the problem of the edge device authentication (and man in the middle attacks) is solved using public-key cryptography. The edge device has an RSA encryption key pair and uses it within IKE to authenticate itself. The user uses the legacy authentication system to authenticate to the edge device. The resulting authentication mode is mutual, yet asymmetric. The proposed hybrid mode is particularly suitable for environments where a legacy authentication system is deployed, yet public key cryptography can be used by the edge devices. The suggested mode is somewhat similar to 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 Litvin, Shamir [Page 2] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 a full-blown public key infrastructure deployment. The authentication modes 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 mode, which is based on challenge-response authentication, it is not possible to put 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). Aggressive mode is thus not suitable even for the simplest challenge-response protocol. We define the new authentication mode for main mode only. Within the suggested main mode, a simple authentication protocol consisting of three messages can be achieved within the six-packet exchange. If more messages need to be sent, main mode is extended and becomes an n-packet exchange (where n>6). There is no defined payload within IKE that is suitable for containing challenge and response messages, and authentication success messages. It is not advisable to define a new payload type, since it breaks existing implementations. In the suggested mode, the Notification Payload [ISAKMP] is used for challenge, response, and status messages. 2.3 The hybrid authentication mode in a nut-shell The participants in the hybrid authentication mode are typically a user, who is the initiator; and an edge device, acting as the responder. The hybrid mode is similar to the "revised encryption mode" [IKE]. The participants negotiate a SA in the first two messages. In the next pair of messages, the user sends her identity encrypted using a key derived from a random string encrypted in the public key of the edge device. The edge device responds with an authentication challenge. The fifth message includes an authentication response from the user. The sixth message includes either a status message (authentication success/failure) in which case the protocol ends; or an additional authentication challenge, in which case the protocol continues. The protocol continues with exchanges of authentication challenges and responses until the responder issues a status message. 3. Terms and Definitions 3.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", Litvin, Shamir [Page 3] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 3.2 Definitions 3.2.1 Notify Message Types The following values can be used within a notification payload: Message Type Value ------------------------------------------------------------------------ AUTHENTICATION-CHALLENGE 16400 AUTHENTICATION-RESPONSE 16401 AUTHENTICATION-SUCCESS 16402 The data part of the notification payload contains attribute-value pairs. The following attributes are defined for use with the above message types: Class Value Type ----------------------------------------------------------------------- Ascii string 1 V User authentication type 2 B S/KEY challenge number 3 B Reserved for future use 4 - 16383 Private use 16384 - 32767 The following values are defined for use with the "User authentication type" attribute: Fixed password 1 OS password 2 S/KEY 3 SecurID 4 SecurID new PIN mode 5 SecurID next passphrase mode 6 Axent 7 Reserved for future use 8 - 32767 Private use 32768 - 65535 If the notify message type is AUTHENTICATION-CHALLENGE, the "Ascii string" attribute SHOULD be included in the data part of the notification payload. At least one of the above attributes ("Ascii string", "User authentication type", or "S/KEY challenge number") MUST be included in the data part of the notification payload. If the notify message type is AUTHENTICATION-RESPONSE, the "Ascii Litvin, Shamir [Page 4] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 string" attribute MUST be included in the data part of the notification payload. 3.2 Notation This document follows the notations defined in [IKE]. In addition, the following notations is used: NOTIF (and any derivative such as NOTIF_j) is the notification payload. 4. Description of the Hybrid Authentication Mode The hybrid mode is based on the existing "revised encryption mode" [IKE]. For reasons discussed above, it is designed to work only within main mode, and not within aggressive mode. The client uses a previously known server public key to encrypt a secret key, much like in the "revised encryption mode". If the client does not know the server's public key, it can request it in the first IKE message, using the Certificate Request payload [ISAKMP]. The server issues a first authentication challenge string (e.g. "Enter your SecurID pass phrase" or "Enter S/KEY entry number 17"). The client responds, and the challenge-response protocol continues until the server issues a message saying that the authentication succeeded or failed. The number of challenge-response rounds is unlimited. When using the hybrid mode for authentication, Main Mode is defined as follows ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, Ke_i --> HDR, Ke_ir, Ke_ir, Ke_ir, <-- Ke_ir HDR*, HASH_I, NOTIF --> <-- HDR*, HASH_R, NOTIF If additional challenge-response exchanges are necessary, the protocol continues until the Initiator is authenticated or denied authentication. In this case, the protocol continues as follows: HDR*, HASH_1, NOTIF_1 --> Litvin, Shamir [Page 5] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 <-- HDR*, HASH_2, NOTIF_2 . . . HDR*, HASH_n-1, NOTIF_n-1 --> <-- HDR*, HASH_n, NOTIF_n Where for j = 1,...,n: HASH_j = prf(SKEYID_a, _b) To derive Ke_ir, first compute: Ne_ir = prf(Ni_b, CKY_R) Next, derive Ke_ir from Ne_ir in the manner described in appendix B of [IKE] used to derive symmetric keys for use with the negotiated encryption algorithm. All other definitions are taken from the description of the revised encryption mode [IKE]. The notification payloads sent by the client (Initiator) MUST be of type AUTHENTICATION-RESPONSE. The notification payloads sent by the server (Responder) MUST be of type AUTHENTICATION-CHALLENGE, except for the last notification, which MUST be of type AUTHENTICATION- SUCCESS or AUTHENTICATION_FAILED (defined in [ISAKMP]). The last message in the exchange MUST be from the server (Responder) to the client (Initiator). 5. Implementation hints The user in the suggested mode is always assumed to be the Initiator. Implementations must take into account that the user must always initiate when implementing rekeying of Main Mode, recovery from server shutdowns, and other scenarios where renegotiation of Main Mode is required. When using a generic authentication protocol, such as RADIUS, the challenge and response messages are passed back and forth using the "Ascii string" attribute. Using the attributes "User authentication type" and "S/KEY challenge number", the authentication process on the initiator's machine can be fully automated. The IKE application can hook into authentication APIs (such as Security Dynamic's SoftID, or S/KEY libraries) to perform the authentication without user intervention. Litvin, Shamir [Page 6] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 6. Security Considerations Previously suggested hybrid authentication modes introduced the concept of a shared password, which is known by a community of users and edge devices, and can thus be used to authenticate the edge device and prevent man in the middle attacks. This approach has obvious security weaknesses: a secret shared by a large community cannot be treated as a real secret. By using public key based authentication these weaknesses are overcome. The suggested authentication mode provides hiding of identities. For mobile IP clients using a fixed password for authentication, this is the only currently defined mode that achieves hiding of identity. Main mode cannot be used with pre-shared secrets in mobile IP scenarios, and aggressive mode does not provide hiding of identity. When using fixed passwords for user authentication, the suggested mode has an additional advantage over the pre-shared secret mode: the password is not prone to dictionary attacks, since the password is encrypted using a derivative of the Diffie-Hellman shared secret. Only the participants in the IKE protocol know the shared secret. It is possible to probe user identities using the suggested mode, unless the edge device takes measures to prevent this. The user identity is sent in the third message. If the identity is unknown to the edge device, it may not respond at all, or respond with an appropriate notification. In both cases, an attacker can deduce that the identity is not defined. This enables an attacker to probe user identities. A possible solution is to always respond to the third message in the exchange, and continue the protocol normally. In the sixth packet, the edge device can send an "authentication failure" notification. In this case, an attacker will not know whether the authentication failed or whether the user is not recognized at all. The problem with this solution is that it requires some computational overhead (RSA decryption and Diffie-Hellman shared-secret computation). This problem is not worse than other IKE modes (e.g. "revised encryption aggressive mode" [IKE]). Implementers must decide which mode of operation is preferable for their needs. Litvin, Shamir [Page 7] INTERNET DRAFT A Hybrid Authentication Mode for IKE JUNE 1998 7. 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)", draft-ietf-ipsec-isakmp-oakley-08 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 9, draft-ietf-ipsec-isakmp-09.{ps,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 Litvin, Shamir [Page 8]