Internet Engineering Task Force Y. Dayan
IP Security Working Group S. Bitan
Internet Draft Radguard
Expires in six months October 1999
IKE Base Mode
<draft-ietf-ipsec-ike-base-mode-01.txt>
Status of this Memo
This document is a submission to the IETF IP Security Protocol
(IPSEC) Working Group. Comments are solicited and should be
addressed to the working group mailing list (ipsec@lists.tislab.com)
or to the editor.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a new Phase I mode for IKE [RFC-2409] based
on the ISAKMP [RFC-2408] Base Exchange. The purpose of this new
exchange is to allow support of all authentication methods with fixed
and non-fixed IP addresses, while offering protection against a
denial of service attack aimed at costly operations. It also enables
negotiation capabilities beyond those offered by Aggressive Mode
(DH/EC group). The exchange consists of only four messages and
therefor is useful when performance is crucial.
Dayan,Bitan [Page 1]
Internet Draft IKE Base Mode October 1999
1. Introduction
The IKE [RFC-2409] protocol offers two modes in which to execute
Phase I - Main Mode and Aggressive Mode. Main Mode offers identity
protection and the cookie mechanism that provides some protection for
the exchange. Main Mode with pre-shared key authentication requires
knowledge of the peer's pre-shared key prior to the knowledge of the
peers identity. Therefore, Main Mode with pre-shared keys can only be
used when the IP address of the peer is the identifier of the peer.
Hence, when using pre-shared keys in an environment where the IP
address does not identify the peer, Main Mode cannot be used.
In Aggressive Mode, the identities appear in the first two messages.
Aggressive Mode is the only mode possible in the above scenario. It
consists of fewer messages and as a result, the cookies are of little
use to the responder. The keying material payload appears in the
first message of Aggressive Mode and therefore an agreement on the
Diffie-Hellman group id cannot take place.
In both modes, the responder MUST always supply the key exchange
payload prior to any authentication of the initiating peer. Creation
of the key exchange payload requires a costly calculation. This
leaves the responder exposed to denial of service attacks. Although
implementation notes have addressed this to some extent, this can
still be seen as a security risk.
This document describes a new Phase I mode that is based on the
ISAKMP Base Exchange. Its purpose is to offer an alternative exchange
that eliminates the above mentioned issues. The initiator's
authentication data is sent along with the key exchange payload,
allowing the responder to verify the identity before replying with a
KE payload. This mode allows the shared secret calculation to be
postponed untill after the exchange is complete. It provides a short
exchange with negotiation capabilities for the Diffie-Hellman (or EC)
group id and security benefits that are discussed in details in
section 4. In an environment with pre-shared keys and addresses which
do not identify the initiator, this is the only alternative to
Aggressive Mode.
The reader is assumed to be familiar with most of the terms and
concepts described in the ISAKMP [RFC-2408] and IKE [RFC-2409]
documents.
2. Specification of Requirements
This document shall use the keywords "MUST", "MUST NOT",
"REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
Dayan,Bitan [Page 2]
Internet Draft IKE Base Mode October 1999
"RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They
are to be interpreted as described in [RFC-2119] document.
3. The Base Mode Exchange
Base Mode is an instantiation of the ISAKMP Base Exchange with the
minor change of the identity payload location. The first two messages
negotiate policy, exchange ancillary data necessary for the exchange,
and identities. The third and fourth messages exchange Diffie-Hellman
public values and authenticate the peers.
The XCHG for Base Mode is ISAKMP Base.
The final messages are not sent under protection of the ISAKMP SA,
and HASH_I and HASH_R have been changed to allow each party to
postpone exponentiation, if desired, until negotiation of this
exchange is complete. The shared secret will only be required in the
following exchange.
Unlike Aggressive Mode, Security Association negotiation is not
limited and the responder provides a Diffie-Hellman public value only
after the initiator authenticates itself.
The value HASH_I needs to be redefined because the initiator must
calculate it before receiving the Diffie-Hellman public value of the
responder. HASH_I is calculated separately for the different
authentication methods.
For signatures:
HASH_I = prf(hash(Ni_b | Nr_b), g^xi | CKY-I | CKY-R | SAi_b |
IDii_b)
For public key encryption and pre-shared keys:
HASH_I = prf(SKEYID, g^xi | CKY-I | CKY-R | SAi_b | IDii_b)
To enable postponing of the calculation of g^xy with the signature
authentication method, we redefine HASH_R for signatures and leave it
unchanged for all other authentication methods. For signatures:
HASH_R = prf(hash(Ni_b | Nr_b), g^xi | g^xr | CKY-I | CKY-R | SAi_b |
IDii_b)
3.1. Base Mode Authenticated with Signatures
Signing a mutually obtained hash authenticates this exchange. This
signatures provide a proof of participation in the exchange.
Dayan,Bitan [Page 3]
Internet Draft IKE Base Mode October 1999
Initiator Responder
HDR, SA, Idii, Ni_b =>
<= HDR, SA, Idir, Nr_b
HDR, KE, [CERT,] SIG_I =>
<= HDR, KE, [CERT,] SIG_R
The signed data, SIG_I or SIG_R, is the result of the negotiated
digital signature algorithm applied to HASH_I or HASH_R respectively.
The hash function to be used with the signature is as defined in IKE,
as is the signature encoding. One or more certificate payloads MAY be
optionally passed. If necessary, a certificate request payload can be
passed in any of the first three messages.
3.2. Base Mode Authenticated with Public Key Encryption
Using public key encryption, the peer authenticates by being able to
decrypt the encrypted nonce, and produce the correct HASH_I/HASH_R.
The verification process in itself requires a public key operation.
The advantage is that the identities are protected. There is an
underlying assumption that the initiator has the responder's public
key from the beginning of the exchange.
Initiator Responder
HDR, SA, [HASH(1),]
<IDii_b>Pubkey_r,
<Ni_b>Pubkey_r =>
HDR, SA, <IDir_b>PubKey_i,
<= <Nr_b>PubKey_i
HDR, KE, HASH_I =>
<= HDR, KE, HASH_R
All details concerning HASH(1) and the encryption are the same as in
Main and Aggressive Mode.
There is no proof that the exchange ever took place since each party
can completely reconstruct both sides of the exchange. The responder
MUST perform four public key operations and these operations take
place before it can verify the initiator's identity.
Dayan,Bitan [Page 4]
Internet Draft IKE Base Mode October 1999
3.3. Base Mode Authenticated with Revised Public Key Encryption
This method is much like the previous one. Its two main advantages
are that there are only two public key operations and that extra
protection is added by encrypting the keying material payload.
Initiator Responder
HDR, SA, [HASH(1),]
<Ni_b>Pubkey_r,
<IDii_b>Ke_i =>
HDR, SA, <Nr_b>PubKey_i,
<= <IDir_b>Ke_r
HDR, <KE>Ke_i, HASH_I =>
<= HDR, <KE>_Ke_r, HASH_R
All details concerning HASH(1) the public key operation details and
Ke_i/r, are the same as in Main and Aggressive Mode. In this method
the responder has to perform two public key operations prior to
verifying the initiator's identity.
3.4. Base Mode Authenticated with Pre-Shared Keys
When doing a pre-shared key authentication, Base Mode is defined as
follows:
Initiator Responder
HDR, SA, Idii, Ni_b =>
<= HDR, SA, Idir, Nr_b
HDR, KE, HASH_I =>
<= HDR, KE, HASH_R
The responder has no costly operations to perform prior to
verification of the initiator's identity. The identity payload can be
used as a pre-shared key identifier. This enables two parties to use
more than one key for authentication. This exchange does not provide
proof that it ever took place since both peers have knowledge of the
pre-shared key(s).
4. Security Considerations
Base Mode with public key signatures or pre-shared keys SHOULD NOT be
Dayan,Bitan [Page 5]
Internet Draft IKE Base Mode October 1999
used when identity protection is required. An exception might be when
the ID payload is used as a key identifier, and the identity is not
explicitly transmitted. In all authentication methods there is no
need to calculate g^xy prior to verification of the peer's identity,
authentication and completion of the exchange.
In all authentication methods, the responder's Diffie-Hellman public
value is used only after verification. This feature is not offered by
Aggressive Mode and Main mode offers it, only to an extent, by the
cookie mechanism. Therefore, for pre-shared key authentication, when
the IP address is not an identifier, this exchange is the only one
that offers some protection from denial of service attacks.
The signatures, in Base Mode with signatures, are over data that was
sent in the exchange in the clear. This makes the public key pair
more vulnerable to known plaintext attacks.
Note that although Base Mode offers more protection from DoS in terms
of costly computations, the responder still needs to create a state
after receiving the first message.
5. References
[RFC-2408] Maughan D., Schertler M., Schneider M., Turner J.,
"Internet Security Association and Key Management Protocol (ISAKMP)",
November 1998.
[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
November 1998
[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", March 1997
6. Authors' Addresses
Yael Dayan <yael@radguard.com>
Sara Bitan <sarab@radguard.com>
Radguard Ltd.
Atidim Technology Park, Building 4
Tel Aviv 61561
Israel
Phone: +972-3-765-7983
Dayan,Bitan [Page 6]
