Re: Son of IKE: A proposal for moving forward

[Michael Thomas <mat@cisco.com>]

Dan Harkins writes:
 >   Mike,
 > 
 > On Thu, 13 Jun 2002 09:49:50 PDT you wrote
 > > 
 > > I'm not sure that that's what I meant, but I can
 > > see how it would be construed that way. As I said,
 > > I'm rather schizophrenic about this issue. We
 > > really, really need to enable strong auth on the
 > > next gen of IP widgets -- ie, things that aren't
 > > going to have 80GB disks and 512MB of ram to
 > > fritter away.
 > 
 > The problem with such hyperbole is that it tends to get
 > traction.
 > 
 > No key management protocol under consideration requires 80GB disks
 > or 512MB or any kind of "frittering". And in fact, IKE has been 
 > implemented on such small IP widgets as PDAs and cellphones.
 > 
 > > Ted's right that Moore's law eventually solves
 > > this, but that's a rather facile arguement if it
 > > solves it *too late*. That is, if the next gen of
 > > widgets either do without strong auth altogether,
 > > or find something like WEP which is "easier" to
 > > implement at the cost of near complete insecurity,
 > > we're not doing the user base any favors.
 > > 
 > > Frankly, I don't think that we're really at the
 > > point where we can handwave things away with
 > > Moore's law: there's a whole new generation of
 > > cheap wireless widgets on the horizon and they
 > > have a hard time swallowing IKE as it's currently
 > > defined. Nor do they seem to need a lot of what
 > > IKE has to offer: cell phones seem to work pretty
 > > OK with simple SIM based authentication. That is,
 > > their needs seem simplier than your average road
 > > warrior.
 > 
 > Right, they need what IEEE802.1x and the EAP WG are providing. 
 > Although I find it hard to understand arguments that talk
 > about the bulk of IKE but suggest that EAPoL (several state
 > machines) encapsulated EAP packets (another state machine) which
 > encapsulate (sometimes fragmented!!!) TLS packets (another huge
 > state machine), supporting all the certificate infrastructure that
 > requires, is somehow less bulky. That's a monsterous amount of
 > interconnected code. But somehow that's OK while IKE is 
 > bloatware. 
 > 
 > The handwaving is not over Moore's Law, it's over some vague
 > "cheap wireless widget on the horizon". In fact, it's almost beyond
 > handwaving to outright fearmongering. Both of the protocols under
 > consideration are less heavy-weight than IKE and IKE has been
 > implemented on PDAs and cellphones. 
 > 
 > > This is why I wonder if there are two problem
 > > spaces. You've taken this to mean my suggesting
 > > that the split should VPN/not-VPN, but that's
 > > just one way to carve the problem space up.
 > > Another might be to differentiate via remote
 > > access, or some other split. A third way to deal
 > > with this is to potentially legitimize "profiles"
 > > where we have a very slim inner protocol which can
 > > and should be implemented by *everything* where
 > > you have additional functionality layered on 
 > > through, say, different standard's track RFC's,
 > > or whatever.
 > > 
 > > The bottom line is that I'm much more interested
 > > that this issue is considered seriously than any
 > > particular way to solve it. When I floated the
 > > JFK/IKEv2 split, it was mainly because I can see
 > > how to make JFK a very light weight -- but still
 > > useful -- means of establishing transport and
 > > tunnel mode SA's. I like IPsec, generally, because
 > > it opens a lot of options. It would be really nice
 > > to have a base level keying mechanism which would
 > > be shameful not to implement. I think that's
 > > within reach right now, even if the kitchen sink
 > > is not.
 > 
 > You can't "make JFK very light weight"; it is not an extensible
 > protocol. You have mutual, public-key based authentication,
 > period. No SIM card authentication is possible. You can't take
 > some and leave some, and you definitely can't add some. It's not
 > that kind of protocol. If the widget you describe above is happy
 > with SIM-based authentication then it will not be happy with JFK
 > just as it is not happy with IKE, as you claim.

Dan,

Rather than going down the lines of debating fell
creatures like EAP-TLS (ack, ptui), maybe it would
be better to go the constructive route here and
see whether we can make a SOI such that there just
can't be any realistic arguments why a widget
vendors can't implement it. As I've said, I've
done some experimenting and I can fit a usable
keying + crypto solution into about 30-40kb of
code including the crypto and modular arithmetic
libraries. This is down about an order of
magnitude from a typical IPsec/IKE stack. At that
cost, I cannot see how a reasonable widget maker
could balk. At 10 times the cost, I have seen them
balk many, many times. And as you know, I work for
an employer who doesn't have a particularly good
record of, er, keeping bloat down, so I imagine
that at shops where pennies are the difference
between negative and positive margins, it would be
even harder.

How did I do this?

1) Cut the complexity of the state machine
   by not having to deal with phases
2) Cut the complexity of SA keying and general
   accrued kruftiness 
3) Cut the number of required identity modes
   to exactly one (eg, using raw DH public 
   identities, though RSA could be added for
   about a 5kb cost).

So, it just so happens that after I did this (I
whimsically called it SPUNK -- StopgaP Ugly
Network Keying), I noticed that it ended up
looking a whole lot like JFK, and then proceeded
to see if I could transmogrify it into JFK, which
was relatively straightforward.

So the real question to you is whether you can do
something similar with IKEv2, and whether we can
structure SOI such that we can have a base level
standards compliant keying mechanism which is
extremely hard for vendors to blow off because it
costs too much -- and then proceed to implement
junk like WEP and other lame L2 isms.

My gut level feeling is that IKEv2 could certainly
be trimmed down considerably if we you took
similar measures as I did above. I doubt it will be
as small as what I managed, but _here_ discussions
of Moore's law might be relevant because the
difference between 30-40k and 50-60k might not be
large enough to quibble about (unlike the
perceived cost of 500k).

After all, if the end result is a single protocol
which has these space savings, I'm certainly not
going to complain. But then I'm not sure if this
is even achievable with IKEv2 -- or whether you
and your other authors think this is just a load
of hooey, which might bring us back to my original
question of whether there really are two
incompatible problem spaces.

		     Mike