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

Re: Simplifying IKE


Dan McDonald wrote:
> 
> > >From the Schneier and Ferguson analysis we get:
> >
> > > 1: eliminate transport mode

IPsec changes don't simplify IKE, at least not to any extent that
would help anyone, and should not be considered.

> > > 2. eliminate the AH protocol

AH is useless, so yes, although it doesn't really simplify IKE.

> > > 3. modify ESP to always authenticate; only encryption should be
> >        optional

I don't care. Our product will refuse to do ESP without authentication in any case.

> > 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?

I guess someone in past figured out that running IKE on satellite lines
is necessary, so they decided to optimize as much as possible. The result
was that both aggressive mode and quick mode both have three messages.
The problem with three messages is that the initiator will often start sending
actual traffic too soon, or quick mode packets, before the responder is ready. Thus 
the need for packet buffers, commit bit, whatever. This optimization causes design 
complications that I'd very much prefer to get rid of.

Thus my preference would be to have a four packet phase 1 (base mode) and
a four packet quick mode.

The other reason I prefer base mode is that the responder can select the
proper policy based on the first packet.

If main mode had the possibility to send a group identity in packet one
and actual identity in packet five, I wouldn't object to just having main mode,
since it does have an even number of packets.

> 
> >     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!

It would be good to specify exactly when they are to be sent.

> 
> >     PFS is currently optional. Why not require it?
> 
> Agreed.

It's useless, so it should be thrown out. Just reduce phase 1 lifetime
or use a larger DH/elliptic group in phase 1.

And specify re-keying exactly.

> 
> > 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).

Manual keying is useless. Preshared keying is useful in some cases.

Ari

-- 
Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Integrated Solutions for Enterprise Security
Follow-Ups: References: