[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: