Internet DRAFT - draft-kaufman-ipsec-improveike
draft-kaufman-ipsec-improveike
Internet Engineering Task Force Charlie Kaufman
IP Security Working Group Iris Associates
Internet Draft Radia Perlman
Sun Microsystems
Andrew Krywaniuk
Alcatel
July 9, 2001
Code-preserving Simplifications and
Improvements to IKE
<draft-kaufman-ipsec-improveike-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPsec) Working Group. Comments are solicited and should be addressed
to the working group mailing list (ipsec@lists.tislabs.com) or to the
editor.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 made obsolete 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.
Copyright Notice
This document is a product of the IETF's IPsec Working Group.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Kaufman et al Expires February 9, 2002 [Page 1]
Internet Draft IKE Improvements July 12, 2001
Abstract
This internet draft recommends modifications to Phase 1 IKE that will
minimize code changes. We recommend simplification by removing some
of the options, and minimal changes, when they provide a large
increase in functionality, in the remaining portions of IKE.
IPsec Working Group [Page 2]
Internet Draft IKE Improvements July 12, 2001
Table of Contents
1. Introduction.................................................4
2. Specification of Requirements................................4
3. Get Rid of Aggressive Mode...................................4
4. Remove Public Key Encryption Variants........................4
5. Allow stateless operation....................................4
6. Change Parameter Negotiation to Allow Choices................5
7. Fix Main-Mode with Preshared Keys............................5
8. Invert Identity Protection...................................6
9. Additional Functionality.....................................6
9.1 Unidirectional Authentication................................6
9.2 Weak Preshared Secret Authentication.........................7
10. IANA Considerations..........................................7
11. Security Considerations......................................7
12. References...................................................7
IPsec Working Group [Page 3]
Internet Draft IKE Improvements July 12, 2001
1. Introduction
IKE has received criticism for being too complex. Rather than
starting over, we recommend changes to IKE that are as code
preserving as possible. For more analysis of these recommended
changes see [PK01] or [PK00]. The reader is assumed to have some
knowledge of IKE. Each section is a separate recommendation for
something that significantly simplifies IKE, fixes bugs, or adds
significant functionality.
2. Specification of Requirements
This document makes recommendations rather than specifying
requirements.
3. Get Rid of Aggressive Mode
If identity hiding is considered important, then use it all the time.
If smaller numbers of messages are important, then always use
aggressive mode. Users are unlikely to understand the choices in
order to decide which mode to use. The optimization of sometimes
being able to use fewer messages, in ill-defined cases, seems not
worth the complexity of doubling the number of permutations that need
to be designed and implemented.
4. Remove Public Key Encryption Variants
Signature-only public keys are useful because they are less likely to
be escrowed, it is unlikely that someone would have an encryption key
but not a signature key, and each side knows its own signature key.
IKE protocols using public encryption keys do not have significant
advantages over public signature key SA establishment.
Furthermore, the public encryption key variants are operationally
awkward because they require the initiator to already know the
responder's public key. Rather than fixing this flaw, which would
require significant redesign of the protocols, it seems better to
merely remove the public encryption variants.
5. Allow stateless operation
The idea of stateless cookies, as envisioned by Photuris, was that
Bob need not keep state until he is assured that the initiator can
IPsec Working Group [Page 4]
Internet Draft IKE Improvements July 12, 2001
receive from the IP address she claims to be coming from. IKE does
not allow Bob to be stateless, since he has to remember the
information (such as the crypto suites that Alice offers) from
message 1 in order to validate Alice's signature in message 5. If
Alice repeats all the information from message 1 in message 3, Bob
can be stateless until message 3.
6. Change Parameter Negotiation to Allow Choices
Sometimes several cryptographic algorithms work together. But IKE
currently requires every combination to be specified. There are four
types of crypto algorithms for each suggested suite (encryption
algorithm, hash algorithm, authentication algorithm, and Diffie-
Hellman group).
If in many cases several of them can be used interchangeably, this
causes an exponential explosion to specify all supported
combinations. Instead we suggest a set of proposals, where there is
allowed to be a choice of algorithms within a proposal. For instance:
proposal 1: ({Enc-A, Enc-B}, MD5, {RSA public signature keys, RSA
public keys with new protocol}, {DH group 1, DH group 2, DH group 3})
proposal 2: ({Enc-C, Enc-D, Enc-E}, SHA, preshared keys, {DH group 1,
DH group 4})
7. Fix Main-Mode with Preshared Keys
In IKE as currently specified, Alice sends her identity to Bob in a
key encrypted with a key which is a function of the pre-shared key.
So Bob can't decrypt the message to discover Alice's identity, unless
he knows Alice's identity. IKE's solution is to require Alice's
identity to be her IP address.
But then there's no reason to use the extra messages to do identity
hiding. Worse yet, it's useless in the "road warrior" case where
someone might configure a shared secret between their laptop and the
firewall, and attempt to connect from unpredictable locations on the
Internet, since their IP address will change.
The solution is to change the key used to encrypt Alice's identity to
be only a function of the Diffie-Hellman key. The protocol already
assures that Alice proves knowledge of the preshared key because she
transmits something to Bob that is a hash of information including
that key. This minimal change (changing the encryption key used for
encrypting messages 5 and 6 to not be a function of the shared key)
IPsec Working Group [Page 5]
Internet Draft IKE Improvements July 12, 2001
allows use of arbitrary identifiers and makes this mode work for the
road warrior case.
8. Invert Identity Protection
In the case of main mode with public key signatures, Bob's identity
is hidden even from an active attacker, but Alice's identity is
exposed to an active attacker impersonating Bob's address to Alice.
We argue that it is preferable to hide Alice's identity rather than
Bob's. The protocol could be modified to hide Alice's identity
instead of Bob's from an active attacker. This would be done by
moving the information from msg 6 into msg 4. This even completes the
protocol in one fewer message.
9. Additional Functionality
The previous sections are either suggested simplifications or fixing
problems. This section suggests two possible enhancements.
9.1 Unidirectional Authentication
In some cases only one side has a cryptographic identity. For
example, a common use case for SSL is where the server has a
certificate and the user does not. In this case SSL creates an
encrypted tunnel. The client side knows it is talking to the server,
but the server does not know to whom it is talking. If the server
needs to authenticate the user, the application typically asks for a
name and password.
The one-way authentication is vital in this case because the user has
to know he is sending his password to the correct server, and the
protocol also ensures that the password will be encrypted when
transmitted. In some cases security is useful even if it is only one-
way. For instance, a server might be disseminating public
information, and the client would like to know that it is receiving
this information from a reliable source, but the server does not need
to authenticate the client.
Since this is a useful case in SSL, it would be desirable to allow
for unidirectional authentication within IPSec. None of the IKE
protocols allow this.
IPsec Working Group [Page 6]
Internet Draft IKE Improvements July 12, 2001
9.2 Weak Preshared Secret Authentication
The IKE protocol for pre-shared secrets depends on the secret being
cryptographically strong. If the secret were weak, say because it was
a function of a password, an active attacker (someone impersonating
one side to the other) could obtain information with which to do an
off-line dictionary attack. Our suggested improvement to the protocol
still requires a strong pre-shared secret.
There is a family of protocols in which a weak secret, such as one
derived from a password, can be used in a cryptographic exchange in a
way that is invulnerable to dictionary attack, either by an
eavesdropper or someone impersonating either side. The original such
protocol, EKE, worked by encrypting a Diffie-Hellman exchange with a
hash of the weak secret, and then authenticating based on the strong
secret created by the Diffie-Hellman exchange.
The ability to use a weak secret such as a password in a secure way
is very powerful, in the case where it is a user being authenticated.
The current IKE pre-shared secret protocol could be replaced with one
of these protocols at no loss in security or performance. If an IKE
weak secret variant were designed, then the strong secret variant
should be dropped, since certainly a protocol that works with a weak
secret will work with a strong secret.
10. IANA Considerations
This document does not require any assigned numbers.
11. Security Considerations
The suggested changes simplify IKE considerably, at no loss in
security. Some changes, such as allowing stateless operation, enhance
the security of IKE.
12. References
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998
[PK00] Perlman, R., Kaufman, C., "Key Exchange in IPSec: Analysis of
IKE", IEEE Internet Computing Journal special issue on
Security Solutions, Nov/Dec 2000.
[PK01] Perlman, R., Kaufman, C., "Analysis of the IPSec Key Exchange
IPsec Working Group [Page 7]
Internet Draft IKE Improvements July 12, 2001
Standard", WET-ICE security conference, MIT,
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf,
2001.
Authors' Addresses
Charlie Kaufman
Iris Associates
E-mail: ckaufman@iris.com
Radia Perlman
Sun Microsystems
E-mail: radia.perlman@sun.com
Andrew Krywaniuk
Alcatel Networks Corporation
600 March Road
Kanata, ON
Canada, K2K 2E6
+1 (613) 784-4237
E-mail: andrew.krywaniuk@alcatel.com
The IPsec working group can be contacted via the IPsec working
group's mailing list (ipsec@lists.tislabs.com) or through its chairs:
Theodore Y. Ts'o
tytso@MIT.EDU
Massachusetts Institute of Technology
Barbara Fraser
byfraser@cisco.com
Cisco Systems
Expiration
This document expires February 9th, 2002.
IPsec Working Group [Page 8]
