[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Simplifying IKE

The Leech, Schiller and Bellovin (LSB?) document mentions:

> the goal: to produce a more secure, simpler, and more robust version of IKE.

I thought it might be useful to inventory some proposed simplifications. Of
course I'll toss in my own opinions while I'm at it, but my goal is less to
get them accepted than to provoke discussion.

>From the Schneier and Ferguson analysis we get:

> 1: eliminate transport mode

It would be possible to eliminate tunnel mode instead, and just use IP-in-IP
over transport where required, but it seems simpler to treat transport as a
degenerate tunnel instead. Either mode can do everything we need, so we need
only one mode. My vote is for tunnel.

> 2. eliminate the AH protocol
> 3. modify ESP to always authenticate; only encryption should be
       optional

Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile
IP actually need AH. Could anyone who needs it speak up again?

If it turns out there are really good reasons to keep AH, then I'd say the
simplification is:

2a: eliminate ESP authentication
3a: require AH on all packets. No choice, no null mode. An IPsec connection
       authenticates all packets, period.

> 4. modify ESP to ensure it authenticates all data used in the deciphering
         of the payload

This is the only recommendation in this paper based on a direct security
flaw, with a proposed attack to demonstrate it. There are others in the
Simpson paper.

I'd say these are the most urgent criticisms, definite entries on the
requirements list for Son of IKE.

( By the way did "Ike" Eisenhower have a son, and should we rename the
  protocol? )

> 5. Remove the weak key elimination requirement. ... algorithms that
       have large classes of weak keys ... should simply not be used.

Of these, 1, 2, 3 and 5 are straightforward. Methinks these changes 
should just go straight into the draft text for "Son", unless strong
objections are raised by this post.

Number 4 is a design task. Volunteers? Is there an existing draft I've
missed?

Then there are possible simplifications not recommended in the Schneier
and Ferguson paper.

We currently have MUST do main mode, SHOULD do aggressive mode, and
there's been discussion of a third mode. Could we cut it to one mode?

There are too many optional items.

    Can we drop the commit bit?

    Can we drop some (or even all?) of the optional notify messages?
    Or perhaps make them required and authenticated, and therefore
      more useful?

    PFS is currently optional. Why not require it?

In general, review optional items with the intent of dropping as many 
as possible and making any really useful ones mandatory. This would
eliminate quite few interoperation problems.

Manually-keyed connections and auto-keyed connections using pre-shared
keys for authentication are currently required. Could we drop either
or both, given that public key authentication has serious advantages
over them? Some discussion of the advantages is at:
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose

To do this, we would have to specify support for at least one public
key technique as a MUST. I'd say RSA was the obvious possibility, and
we should have only the one MUST for simplicity.

We should also specify a common format for transfer of public key 
information -- preferably by pointing to an existing spec, rather
than re-inventing -- and require everyone to import and export keys
in that format, whatever they choose to use internally. That way two
implementations that need to interoperate can get each others' keys.

For ciphers, we currently have DES and null encryption as the only
MUSTs, although we should all know DES is inadequate. 3DES is a
SHOULD, although it is dreadfully slow compared to either the CAST
and Blowfish generation of ciphers or to AES. 

I'd like to see AES as the only MUST, with null encryption and 3DES
as SHOULDs.
Follow-Ups: