RE: RESEND: Thoughts on identity attacks

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

Khaja,

Invariably protocols get designed with options and functionality that
aren't all that important. Sometimes people like to have things that
might prove useful in the future, if they aren't that expensive to
provide, so that a new protocol won't need to be designed if people
do decide the feature is important. Assuming it was possible to have
a radically simpler protocol for most cases, if it were *in addition*
to the more general protocol for the rest of the cases, the total
solution would obviously be more complicated than something that
solves what the WG wants (or thinks it wants).

You are proposing getting rid of identity hiding completely. If that
would make the protocol radically simpler, that would certainly
be a good idea. 

So, the question is, what is the cost of providing identity hiding in
IKEv2? IKEv2 is a four-message exchange that sets up not only a phase 1 SA
but an ESP SA.

How could it be simpler than that? Well, one could make IKEv2 be
a two-message protocol if you gave up not just identity hiding, but
anti-clogging protection of computation and state, ability to send
certificates along with the handshake so you don't need another
mechanism to obtain the other side's cert,
crypto negotiation, rekeying SAs, and the ability to cheaply
create lots of child-SAs off a single IKE SA.

Is all that functionality worth having 4 messages rather than 2?
Once you go with 4 messages, the identity hiding is free. It does
not complicate the protocol.

It seems prudent, if IKEv2 is simple enough, not
to try to remove functionality that a significant
number of people
think is or might be important. That is...IF it isn't really expensive
to provide it. This is all engineering tradeoff stuff...each option that
might be useful makes the protocol slightly more complex. If one goes
overboard, one gets something everyone will clearly say is too complicated.

I think IKEv1 was clearly too complicated, but it wasn't only because
of too many options and
features...it was also that the documents were so hard to understand
and in so many pieces that nobody got a chance to really get the whole
protocol in their heads to think it through and keep it clean. I, at least,
think that the IKEv2 document fits in a mortal's head, and it could
be somewhat simpler if we did, for instance:

a) remove the two phases...I argued for getting rid of phase 2
originally, but I've gotten enough feedback from people who
really want to create lots of phase 2 SAs so that different flows can
use different keys. Also it makes rekeying easy.

b) remove identity hiding entirely...but there are "peer-to-peer" people
who have said they think it might wind up important in certain scenarios,
as well as Charlie K's example of "protecting the customer of the sleazy
porn merchant"

c) remove AH...there are vocal advocates of AH

d) remove crypto negotiation entirely: define one suite, and that's what
IPsec uses. That's undoubtedly too radical, unfortunately. I'd love it
if the protocol said "use AES for encryption, etc." but with changing
export laws, crypto algorithms getting broken, countries and or
organizations wanting to substitute their own crypto, etc., I've
come to accept this as a necessity.

e) change crypto negotiation to entire suites rather than each algorithm
separately...I would like to see this done...it simplifies things somewhat...not
spectacularly...it's really just syntax.

I am always an advocate of simplicity, but in engineering no single factor
outweighs all others. You have to trade off functionality, flexibility, and
time-to-market (which includes getting a WG who has come to want
a certain feature to be willing to get rid of it, which will be a difficult
sell if the feature really doesn't make the protocol significantly
more complicated or expensive). Should the WG argue about getting
rid of all the above in order to have the "simplest possible" protocol,
if it winds up being only slightly simpler?

Radia