[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
At 9:33 PM -0400 8/7/01, Sandy Harris wrote:
>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.
the two modes are not interchangeable, as discussed in my rebuttal to
the paper in question, a year ago. we have advocates for both, and
neither group of advocates, so far, has been willing to give up its
favorite features for the other. the simplest change would be to give
up transport, since tunnel mode can emulate transport, but one incurs
added overhead as a result. also, we now have other protocols, most
notably L2TP, specifying use of transport mode in their RFCs.
>
>> 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?
I'm sure you will hear from those folks.
>
>If it turns out there are really good reasons to keep AH, then I'd say the
>simplification is:
>
>2a: eliminate ESP authentication
are you suggesting removing the authentication option from ESP? ESP
with null encryption is more efficient than AH in most cases, and if
one needs both encryption and authentication, the combined mode use
of ESP is much more efficient. this suggests that this suggestion is
not very attractive.
>3a: require AH on all packets. No choice, no null mode. An IPsec connection
> authenticates all packets, period.
see comments above as to why this is not a great idea.
>
>> 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.
the proposed attack is based on assumptions about independent keying
for AH and ESP (with null auth). IKE won't do this and it is not
clear that anyone has ever done this via manual key management. it's
easy to warn against this, and retain the option for encrypt-only
ESP, which has potential efficiency benefits for situations where
upper layer protocols already provide authentication.
I'll leave comments on your IKE suggestions to others. Note that
since IKE is not the only key management protocol, e.g., KINK will be
available at some point too, changes to supported ESP/AH modes are
not really within scope for a "simplify IKE" discussion.
Steve
References: