One document matched: draft-ietf-ipsec-isakmp-hybrid-auth-01.txt
Differences from draft-ietf-ipsec-isakmp-hybrid-auth-00.txt
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
<draft-ietf-ipsec-isakmp-hybrid-auth-01.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 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 <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
Tamir Zegman <zegman@checkpoint.com>
Check Point
3A Jabotinsky St.
Ramat-Gan 52520
ISRAEL
Litvin, Shamir, Zegman [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-21 21:41:25 |