Internet DRAFT - draft-litvin-ipsec-isakmp-hybrid-auth
draft-litvin-ipsec-isakmp-hybrid-auth
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
<draft-litvin-ipsec-isakmp-hybrid-auth-00.txt>
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), ]
<Ni_b>Pubkey_r,
<KE_b>Ke_i,
<IDii_b>Ke_i -->
HDR, <Nr_b>Ke_ir,
<KE_b>Ke_ir,
<IDir_b>Ke_ir,
<-- <NOTIF_b>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, <NOTIF_j>_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 <moshe@checkpoint.com>
Check Point
3A Jabotinsky St.
Ramat-Gan 52520
ISRAEL
Roy Shamir <roy@checkpoint.com>
Check Point
3A Jabotinsky St.
Ramat-Gan 52520
ISRAEL
Litvin, Shamir [Page 8]
