[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
> >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.
I respectfully disagree. If we require tunnel mode everywhere, we run the
risk of further impacting performance by an additional 20(v4) to 40(v6) bytes
of MTU shrinkage.
If you consider tunnels as "transport with next-header == IP/IPv6", then you
can get all of your tunnel-mode functionality back by indicating a richer
selector set for next-header/protocol == IP/IPv6. It's not tough to picture
things this way.
Here's a table if we eliminate the tunnel mode distinction:
Protocol Selector set
-------- ------------
TCP outer IP addresses, port numbers
UDP outer IP addresses, port numbers
ICMP outer IP addresses, code, type
IP/IPv6 outer IP addresses, inner IP addresses, plus selector
set from inner IP protocol that doesn't include
IP addresses. (If inner IP proto == IP, stop with
inner IP addresses.)
Most of the VPN/router vendors I've seen like the ability to protect
different flows across the tunnel differently. My tunnel implementation
(which treats tunnel mode like a case of transport mode) doesn't distinguish
flows right now, but there's nothing stopping me from doing that in the
future.
> > 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.
Choice 3a was the original intent of the SIPP security architecture (which
became the 182x series of IPsec RFCs). The biggest complainers about AH I've
seen include:
1.) Hardware people who didn't think you could build AH in hardware.
(There are worked counter-examples.)
2.) People who thought AH processing rules were convoluted.
Now #2 folks may have a point, but simplifying AH rules _may_ help there.
The biggest motivator behind AH was to allow an authenticated source route.
Now as Steve Bellovin has pointed out, unless you can configure a hop-by-hop
key, the middle can send that packet anywhere it wants before it reaches the
end.
I wish there were some ISP/ops types on this list (maybe there are and I'm
just being an airhead). I believe the source route header is primarily used
to see what paths are broken in a network - using the process of elimination.
Using AH (or ESP authentication) insures that the packet came from where it
claims to have come from. THAT is why AH was developed, but ESP
authentication can provide a source-routed packet with similar properties.
> > 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.
And if you use Choice 3a above, you get this for free - AH covers the whole
ESP datagram, SPI/IV/etc.
> I'd say these are the most urgent criticisms, definite entries on the
> requirements list for Son of IKE.
None of what you mentioned so far, BTW, deals with IKE. It all deals with
IPsec's basic on-the-wire protocols, none of which were really talked about
in the Security AD's note.
> > 5. Remove the weak key elimination requirement. ... algorithms that
> have large classes of weak keys ... should simply not be used.
No need to change specs to fix this - just issue a BCP/standard on algorithm
choices.
> Then there are possible simplifications not recommended in the Schneier
> and Ferguson paper.
NOW we're in IKE territory...
> 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?
That works for me!
> There are too many optional items.
>
> Can we drop the commit bit?
Who uses it?
> Can we drop some (or even all?) of the optional notify messages?
> Or perhaps make them required and authenticated, and therefore
> more useful?
Hear hear!
> PFS is currently optional. Why not require it?
Agreed.
> 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
Strongly disagree on manual keying. Many outfits use "keying by {Marine
guard, bodybuilder, steganography}". Also a manual keying interface can
allow better automated KM systems to be built (Shameless plug: RFC 2367).
> 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.
Now you're tackling PKI problems. I don't envy you the task, especially
given we have a PKIX group that's probably better equipped to handle this.
> 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.
Works for me. But what about hashes?
Dan
Follow-Ups:
References: