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

RE: Simplifying IKE



I have to admit I started in the "keep tunnelling - los transport" camp, but
with more experience I would definitely prefer transport mode + IP-in-IP.
This makes gateways and end-to-end cases identical.  It also separates
routing issues associated with tunnelling from IPSEC.

I'd also like to see all IPSEC traffic between two hosts carried by just one
SA.  I can't see any value in using multiple SAs between to hosts.  IPSEC
should be just providing a secure pipe between two hosts - what goes through
it is better regulated by a firewall.  There is an argument that you might
want to use different strengths of crypto for performance reasons but there
is generally a focus on performing one type of encryption really well rather
than supporting multiple types.

I'm less keen on AH and would lose it if at all possible.  Authenticated ESP
provides authentication, integrity and anti-replay of the IP payload - what
do you care if the IP header has been tampered with?  (what is missing from
ESP auth - just the destination IP address?).  Per-hop use of SAs currently
appears limited as keys are typically only shared by the end-points.

I would like to see things like null encryption and specific algorithms not
being MUST (or even plaintext bypass).  My main reason for this is that you
can reject these by policy anyway but that exclusion from build is required
for products that go through tough security evaluations.

Chris

> 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/confi
g.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.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.



Follow-Ups: