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

Re: Simplifying IKE (was RE: Reliable delete notifies)



On 11 Oct 00, at 7:58, Andrew Krywaniuk wrote:

> It has been my observation that just about everything we have do for the
> sake of some type of optimization (memory, latency, throughput), has made
> IKE into a more complex and ambiguous protocol.
> 
> Examples: aggressive mode, dangling phase 2s, 3 message quick mode, 2 byte
> CPIs, arcane attribute encoding schemes (which only save a byte or two).
> 
> Why isn't there a message counter in the isakmp header (i.e. MM3)? I know
> it's redundant, but it would sure make the state machine easier on lossy
> networks.
> 
> Forget aggressive mode as an optimization and think only of the security
> properties it gives you: no identity protection (so you can use preshared
> keys) and DoS resistance (trading one attack for another, actually). Base
> mode would cause a lot fewer interoperability problems than aggressive mode
> because it works just like main mode except without the KE. Or we could go a
> step farther, as Bill has suggested, and tweak main mode. (However, I think
> that keeping Base Mode as a separate exchange mode is actually less
> complex.)
> 
> I'm not sure that merging the big 3 documents will actually make IKE easier
> to understand. ISAKMP is fine as it is, as far as I'm concerned. Merging IKE

It probably will. But there is one thing that I'm worried about: 
merging all in one document may close the doors to independently 
enhance protocol parts - every such attempt will require updating of  
this big document. Currently ISAKMP defines the framework in which 
different key management protocols may be defined. Nowdays IKE is the 
only of such protocols, but the room for others is still here. 
Combining everything into one document will probably mean "IKE 
forever" - the approach that I'm not too happy about. 

> and DOI seems more sensible, although I'm worried that they will end up
> being shorter; IKE is too terse already. It should be more restrictive...
> recommend a payload ordering, restrict vendor ids to MM1&2 only, put some
> kind of limitation on rekeying, use a counter for the message id.
> 
> I doubt this is a popular belief, but I would like to see a fourth document,
> something that was hinted at in the Schneier/Ferguson analysis of IKE: an
> explanation of what properties the IKE protocol is meant to have -- a
> derivation of the formulas, e.g. SKEYID derivation, key refresh, cookie
> calculation, what PFS will accomplish, what "uniqueness" of the message id
> means. ;-)

I concur.

> I don't understand the argument about extra algorithms causing
> interoperability problems. Public key encryption has never caused an
> interoperability problem for us because we simply don't support it. I can
> understand how some people might want a non-repudation property in their
> authentication algorithm, and I think the protocol shouldn't limit that, but
> those aren't the kinds of people who buy our products.
> 
> And I don't understand this whole "derive a pre-shared key from a
> self-signed certificate" thing. The whole point of using certificates (IMHO
> only, I have discovered) is that they have extra properties that preshared
> keys do not have (e.g. the fact that they can be publicly distributed
> without revealing the key). If you use the hash of a self-signed certificate
> as a preshared key (in which case you cannot distribute the certificate
> publicly) then you inherit the worst of both worlds.
> 
> TimeStep has supported certificates for 6 years or so, and for intra-domain
> communication they are great. But believe it or not, I have seen situations
> where preshared keys are much easier to deploy than certificates. One
> example is inter-domain communication where the two gateways have different
> trusted roots (and restrictive policy rules). Yes, I know you *can* solve
> this problem using certificates (by cross-certifying the gateways or by
> creating a new domain exclusively for the connection), but I hardly think
> that is easier than using a single preshared key.
> 
> At the heart of this discussion, I think, is an effort to legislate the way
> in which IPsec is used. The IETF overlords can't directly impose their whims
> on customers, so instead they place that burden on us, the implementors.
> This smacks of the whole IPSRA problem. I happen to prefer protocols that
> don't come with a political agenda.

Me too.

> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.

Regards,
Valery Smyslov.


References: