HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward

[[e-mail] (Pekka Nikander)]

Tom already answered to a number of points (and I am trying
to avoid repeating him), but perhaps I can say something
more.

> IMO, it's important to consider IKEv2 for a variety of reasons. The
> biggest reason is that it will improve the usability of HIP. It's a lot
> harder, practically speaking, to convince people to buy/build a new
> product such as HIP when their older products (IKEv2) can already
> achieve something similar. I think we should learn the right lessons
> from IPv6 deployment.

I agree with you that it is important to consider IKEv2, or IKEv3,
in the longer run.  However, right now IMHO the goals of IKEv2 and
the goals of HIP are sufficiently different to warrant a separate
KMP.  On the other hand, as you indicate below, it seems that we've
missed some crucial elements of IKEv2, and should copy them.

More importantly, the atmosphere in the ipsec WG has always been
such that it would have been utterly impossible to develop something
like HIP there.  A large number of ipsec WG members are what I call
"managed security" folks.  In their mind, security always means
administrators and very secure systems.

A large number of people at the HIP wg are what I call "opportunistic
security" folks.  In our mind, there is _also_ value to improve
security in a situation where you cannot afford separate security
managers and where your security goal may not be that high.

HIP aims to both managed and opportunistic security, with more
focus currently on the opportunistic side.

Our current goal is to make IKEv2 and HIP to happily coexist on
a single host.  We are not there yet, but almost.  Once we know
what kind of extensions you need to PF_KEY, I will most probably
write a revision of PF_KEY.

> The basic IKEv2 is no more complex than HIP exchange, IMO.

When I speak about complexity, I mostly mean the number of lines
needed to implement.  With this measure, IKEv2 is considerably
more complex than HIP.  Among other things, the policy negotiation
in HIP is virtually non-existent.

> In addition, the security properties of IKEv2 is well understood. 
> Hugo's
> paper has a provably secure analysis of SIGMA, on which IKE is based.
> This is not the case with HIP key exchange.

The aim in HIP has been to base it on SIGMA.  Apparently we have
missed it, as none of us (except perhaps Bob) are real crypto
protocol experts.  We need to fix this.

I would be very glad if you would outline the necessary _minimal_
changes that are needed to make HIP to be based on SIGMA.

> Well, I didn't find any discussion in draft-moskowitz-hip-arch-06.txt 
> on
> why someone will choose a "low policy granularity" based key-exchange
> (i.e., present HIP) when another one already exists.

Ok, I will add a section on this.

> Also, I am not clear why HIP has lower policy granularity. Isn't policy
> based on the USER_ID (e-mail. FQDN etc.) -- which HIP already has?

I don't remember why and when we added NAI support.  Before that
only FQDN was supported.  I guess it was added to ease integration
with legacy AAA systems.

The aim has been and still is that you use a single logical pair of
SAs between two hosts, and you route all traffic between the hosts
over those SAs.  No selectors used.  Maybe this isn't clear from
the draft.  If so, please suggest added/modified wording.

There are hooks here and there for adding multi-user support so that
you could use a different pair of SAs for each user, but that has
not been defined.

> You mention complexity a couple of times in your e-mail. To me it seems
> like the biggest complexity is reinventing a new key exchange. :-)

Apparently we have missed some finer details of IKEv2.  It is time
now to fix this.  There is no real need to re-invent the security
properties of IKEv2.  We just want to
   a) embed DoS protection which is always usable (not optimised away)
   b) make the protocol middle box friendly
   c) support no selector based policy

I think that we could then later on define a mode of operation
where the mandatory DoS protection can be optionally skipped,
and where people that want to have more selector policy control
can add it.  But such things should be add-ons, not intrinsic
parts of the base protocol.

> Not saying we should not have HIP key exchange. But do add some text on
> why? IESG might as well ask the same question.

Point taken, and will be better addressed in arch-07.

--Pekka