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

[[e-mail] (Yogesh Prem Swami)]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA6864CF482FA156CE4B2953B
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Pekka-

I split the e-mail into different parts. I guess, it's too late in the
game, so I am not going to "fight" too much here, but see inline:

ext Pekka Nikander wrote:

> Good questions and comments, we need more like this.
> 
>> I sent a big part of these comments to the authors directly, but
>> may be it's useful to discuss this on the mailing list as well.
> 
> 
> [I'll answer to that next, after this one, cc:ing the relevant
> parts to the list.]
> 
>> *  Motivation for not using IKE (+MobIKE).
> 
> 
> The original motivation was that IKEv1 is not so well defined.
> To put it bluntly, it was clunky.
> 

When I say IKE, I mean IKEv2. My bad. :-)

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.

Also, the more number of key exchange protocols you have, the more
fragments of secure, but isolated, networks you will have in future.
It's not hard to envision cases where one organization only supports IKE
(because they already spent like crazy on PKI), while the other one only
has HIP.


> The situation is slightly different now.  It might be possible
> to reuse IKEv2 for HIP.  However, it has been an explicit design
> goal to make the HIP base exchange as simple as possible while
> still retaining the overall architectural goals, including DoS
> protection.  From that point of view, IKEv2 is too complex.
>

The basic IKEv2 is no more complex than HIP exchange, IMO. But, I agree
that in case of DoS, there is a possibility of message explosion, but
that's different from complexity (i.e., to me, ping-ponging a few
messages only in case of DoS is not complexity, but a good design choice.)

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. (In SIGMA both sides provide
a proof of possession of the ephemeral key by the HMAC. In HIP only
Responder provides this proof in R2. This can have different, and
unintended consequences... Haven't analyzed it yet, though.)

> One bigger issue is relationship to middlex boxes, though.  HIP
> has been designed to be middle box friendly, explicitly keeping
> fields that middle boxes might inspect, including SPIs, in clear
> text.  IKE favours confidentiality and secrecy here, HIP doesn't.
> 

My preferred approach for middle boxes (some prefer evil-boxes) is to
let the protocol break in its presence. Clearly, I'm in a minority here! :-)

But I see your point. Although, I won't keep the SPI in clear, I can
still live with it. Without SPI encryption, USER_ID encryption alone
looses a few of its of benefits.


>>    The draft needs to motivate the need for a new key exchange
>>    protocol.
> 
> 
> Actually, that is the task of the architecture draft.  If it doesn't,
> or does the job poorly, please indicate which parts of the architecture
> draft you would like to see improved.  (-06 is malformated, I'm
> in the process of issuing -07.  -05 may be easier to read, if you
> can find it.)


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.

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? Do
you mean fancy ways of  authenticating hosts, by policy granularity? I
must be missing something here.

> 
>>    IMO, however, IKE (+MOBIKE) with public-key encryption (which can
>>    be obtained from DNNSec) can achieve almost everything that this
>>    draft achieves.
> 
> 
> Yes it can, with the possible exception of different approach to
> DoS protection.  However, it is considerably more complex than the
> HIP base exchange.


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. :-)
I general, I won't reinvent the wheel if tweaking the existing ones
meets my requirements. Depending upon other protocols is
a good design principle, IMO.

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

More in next e-mail.

Thanks
Yogesh

[[Blanket Disclaimer: All opinions are solely mine, and doesn't
represent the opinions of my employer.]]







--------------enigA6864CF482FA156CE4B2953B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iQEVAwUBQUXyaHkjMhOId4nzAQKYmgf/d7wWotwhZksMsa5eCBW9j4euq51X2qdx
jiyYxHH0BDWrk4Bg9JLfq/poEl0v2z1GNeDStX9b0C7MXwiXdhcSmxKmlXICm0pl
SOR3CuWb0RoZO+pL6rj7XWc4zQJ9PuOUA9tsK4uVjOXQmsEuWO5GWNb5SkQ6tJtH
MCB/Y2Zq8CyeB5MSUgccbCEKolKy5M8fltbfHQmHoXtLavUNGDnI1SoxiXuD0Tof
v8ChG5lmRTO1XGlzraGYR5itaPpMeRextYzf6yHj08Cnsoki/i4CmYprSYBrJRvB
8n/8OLyrAr0KCfJBCiwtxWde/jfOlwEFOPtikzz8BZGC1K6HSzVo3Q==
=64HB
-----END PGP SIGNATURE-----

--------------enigA6864CF482FA156CE4B2953B--