Re: Son of IKE: A proposal for moving forward

[Dan Harkins <dharkins@tibernian.com>]

  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.