Subject: Re: [Hipsec] Moving the base spec forward

From: Yogesh Prem Swami <[email-masked]>
Date: Sat, 11 Sep 2004 16:23:18 -0700 (PDT)

Hi,

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.

Some General Comments:

*  Motivation for not using IKE (+MobIKE).

   The draft needs to motivate the need for a new key exchange
   protocol. If I understand right, there are three different parts
   to HIP. First is the issue of securely naming the TCP/IP kernel.
   HIs and HITs do this job superbly, although any name could do the
   job as long as public-keys could be easily/securely bound to that
   name. The second issue is how to use these HI/HITs to get a security
   association. For this the draft proposes to use HIP exchange.
   IMO, however, IKE (+MOBIKE) with public-key encryption (which can
   be obtained from DNNSec) can achieve almost everything that this
   draft achieves. The third issue is how does the key exchange
   protocol tells the kernel to do IP to HIT flipping (among other
   things).

   BTW, I am not against a new key exchange protocol; just need to
   see some good reason for a new one (for example, if HIP exchange
   will reduce the connection setup latency compared to IKE).

*  A protocol-type just for a key exchange?

    Why do we need a protocol type just for the key exchange. To me it
    seems frivolous to assign a protocol type for a 4 message exchange
    which could very well be done at the application layer using UDP.
    I could not see any advantage of doing the key exchange at IP
    layer. But I can see quite a few disadvantages. The biggest
    disadvantage is that if HIP is implemented in Kernel, every time
    there is a need for an upgrade, for example due to bugs, broken
    (colliding) MACs, broken DH (sub)groups, you will need a kernel
    upgrade. Another disadvantage is that it's hard to log events from
    the kernel in a reliable way. Yet another disadvantage is that
    keeping human-in-the-loop in the authentication process is more
    difficult in the kernel.

    IKE is implemented on UDP for a good reason. HIP draft needs to
    justify why those reasons are not valid.

*  Optimize for most common case.

   The cookie and puzzle mechanisms are quite nice, but it assumes that
   all Initiators are guilty until proved innocent. In the real world,
   however, more than 99% of time hosts are innocent and the puzzle and
   cookie mechanism is just an overhead. A much better case for HIP
   would be to have a one round trip key exchange--with the DoS
   protection switched on only if the responder thinks it's under attack.

   [[   Consider, for example, a simple exchange such as the
          following that can allow the Initiator to start sending data
          right after one RTT.

         1.  I->R:   g^i, HIT-I, HIT-R, nonce-I, Supported-DH-Groups

         2.  R->I:   g^r, HIT-I, HIT-R, nonce-I, nonce-R,
                     encrypt_with_g^ir {[HI-R,]R:   HIT-I, HIT-R,
encrypt_with_g^ir_/_random_key{HI-I,
                     USER_ID-I, SPI-I} HMAC, SIG-I
                     private_key{random_key}

      Under DoS suspicion, or if the DH groups don't match, the
      responder might tell the Initiator to do the puzzle stuff
      with the appropriate difficulty.
     ]]>

Specific comments (assuming people want to keep the key exchange as is.)

* Page-12: I-1 needs to have a type which says what DH groups Initiator
           supports. We should not assume that I-1 can/will-want to
           handle all the DH groups. Additionally, if Responder cannot
           select any of the proposed groups, it should say something.

* Page-12: I think all messages, including I1 should contain a
           nonce/cookie (similar to R1 counter to match incoming and
           outgoing requests) in addition to HITs. For example,
           If the local policy requires one SA per USER_ID,
           then the present key exchange will not be  able to meet these
           requirements.

* Page-12: The key exchange on this page is somewhat unclear. I kept
           flipping between section 4, 7, 6, and 5 (often in that
           order) to figure out which message means what. It will be
           nice to explain all the messages right underneath the
           figure. Also, its not clear which parts of the message are
           included in the signature, and which ones are left out.
           (Of course, if someone reads the entire draft, she'll be
           able to figure out everything. I am just suggesting
           to provide a short description in section 4.)

*  Page-14: The description of what is included in the signature
            for R1 on page 14 and page 51 are inconsistent. On page 14,
            g^r is left out of signature calculation; on 51 it's
            included.

            I would personally prefer the entire signature
            out from R1 (i.e., there is no need for HIP_SIGNATURE_2).
            Removing SIG_2 in R1 doesn't hurt MITM issues because R2
            is still signed. Additionally, I would modify I2 to
            contain HMAC and signature (similar to R2) than just
            a signature. HMAC on I2 proves a lot more than the
            signature alone.

            R2 is okay.

* Page-15: ""The packets R1, I2, and R2 implement a standard
              authenticated DH..."". Draft needs a reference here. I
              guess you mean ISO based scheme here, right?

* Page-16: I'm not sure what is the attacker going to gain from
           replaying R1 and I2. The attacker cannot derive the
           DH keys by replaying R1/I2. She might be able to force the
           Initiator/Responder to solve the puzzle (but that is a lot
           less computation than the Signature verification). So I
           would suggest removing the replay protection text.
           (I would still keep R1-COUNTER as a nonce but not keep states
            across reboots.)

           Warning: I might have missed something here.

           IMO, if more than one R1 or I2, they should all be
           considered valid until a right authentication comes.
           Following IKEv2 design choices...

* Page-16: More text is needed about caching the random number r of g^r
           in R1. BTW, how does this protocol behave if the random
           number r is deleted and g^r arrives after that. It should
           send new g^r and the Initiator should be able to accept it
           (section 8.7 doesn't seem to say anything either. I might
           have missed it.)

*  Page-37: HOST_ID should probably be renamed USER_ID. This field also
            needs a OPAQUE type for unknown HOST_ID types (e.g.,
            cell-phone numbers etc). Also, it might be good to say in
            the introduction that a HOST_ID is different from HITs/HIs,
            just to avoid confusion.

*  The SPIs needs to be encrypted. It provides limited user traffic 
   confidentiality.

*  Page-40: Order of concatenation for signature calculation for
            HIP_SIGNATURE and HIP_SIGNATURE_2 are not clear. It's
            better to use || than text, which is confusing to me.

To summarize, I would prefer the key exchange to look something like:

I->R:   IP( HIP(
        I1-COUNTER    /* just a random number */
        R1-COUNTER    /* = 0 */
        HIP-TRANSFORM /* with list of DH groups */
    ))

R->I:    IP( HIP(
                Both counters;

        no change except remove HIP_SIGNATURE_2

                HOST_ID        /* ? why is this here in clear ? */
                               /* Probably better to move it to R2.
                               ID protection from passive attacker is
                               still a good idea.
                                */
                )
             )

I->R:     IP( HIP(
                Both counters.

        no change, except add a new field HMAC.
                I am not sure if signing the whole message has
                any advantage over just encrypting the HMAC with private
                key.
             )
           )

R->I:      IP( HIP(
        Both counters;

            No change. But Probably better to put encrypted
                        HOST_ID here instead in R1. Before authenticating
                        this message, policies won't be enforced anyway.
        )
       )

Comments?

I think more people need to read this draft before the Last Call. 

Thanks
Yogesh
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Yogesh Prem Swami <[email-masked]>
Date: Sat, 11 Sep 2004 17:37:51 -0700 (PDT)

Oops! I garbled some text during cut-n-paste. Please replace the following text
with the text underneath it.

>                      USER_ID-I, SPI-I} HMAC, SIG-I

[Replace with:]

<![[   Consider, for example, a simple exchange such as the
          following that can allow the Initiator to start sending data
          right after one RTT. (This is just an example. It might have
          security flaws.)

         2.  R->I:   g^r, HIT-I, HIT-R, nonce-I, nonce-R,
                     encrypt_with_g^ir {[HI-R,], USER_ID-R, SPI-R},
                     HMAC(KEYMAT, all previous fields), SIG-R

     At this point Initiator will be able to start sending
     the packets (TCP packets, for example). The responder still
     needs to authenticate the Initiator, but that could be done in
     parallel.

         3.  I->R:   HIT-I, HIT-R, encrypt_with_g^ir_--or--_random_key{HI-I,
                     USER_ID-I, SPI-I} HMAC, SIG-I
                     private_key{random_key}

---

Sorry about that.

Thanks
YOgesh

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 13 Sep 2004 14:57:51 +0300

Good questions and comments, we need more like this.

> 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.

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.

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.

>    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.)

>    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.

> *  A protocol-type just for a key exchange?

Well, architecturally all traffic flows over the new protocol type,
as there is a new layer between IP and upper layers.  Using ESP
is just a convenient shorthand.

>     .... But I can see quite a few disadvantages. The biggest
>     upgrade.

Actually not.  You can easily implement 99% of HIP on user level.
IMHO, it is useful to push I1 handling to the kernel (or even to
a separate node, see the hi3 draft), but do the rest of processing
in user level.  But different implementations are differ.

The rest of your disadvantages don't apply once you realise this.

>     justify why those reasons are not valid.

Again, see the architecture draft, and please indicate if it in your
opinion is not clear enough.

> *  Optimize for most common case.

You can vary the cookie difficulty.  There is nothing wrong in
making K=0 by default.

Currently, the main goal is to keep the protocol as simple as
possible, not to optimise it for any specific use case.

>                      HMAC(KEYMAT, all previous fields), SIG-R

Ever heard about TCP SYN flooding? :-) That is a real problem, even
if CPU exhaustion attacks may not be (yet).

It would be possible to design HIP in such a way that you don't need
I1/R1 exchange (and I know that some people have considered such
variations for various purposes, including broadcast R1s), but that
would add complexity.  Hence, preserved for later consideration.

>            select any of the proposed groups, it should say something.

Good point.  I think we have discussed this before, but I don't know
what were the thoughts about this.  Anyone?

>            then the present key exchange will not be  able to meet 

I don't understand this comment.  Please elaborate.

(Editorial comments left to Petri, the current editor.)

>             is still signed.

No, it doesn't protect against MitM.  It is there to protect the
hosts from certain kinds of replay attacks.  I think the draft
says it somewhere, but maybe it doesn't?

>             Additionally, I would modify I2 to

How come?  I don't understand, but maybe I'm blind.  Supposedly
the Responder hasn't got any state when it gets I2.

>               guess you mean ISO based scheme here, right?

A reference to Hugo's SIGMA paper?

Hugo Krawczyk: SIGMA: The 'SIGn-and-MAc' Approach to Authenticated
Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO 2003: 400-425

>            less computation than the Signature verification).

Not necessarily.  With large K, solving the puzzle takes a lot of CPU.

>            Following IKEv2 design choices...

Good point.  Please elaborate so that we understand better, I haven't
been following IKEv2.

>            (section 8.7 doesn't seem to say anything either. I might

Suggested text to be added?

>             cell-phone numbers etc).

Good point, though I'm a little bit reluctant as it slightly adds
complexity.  HIP is a _Host_ Identity Protocol, after all, even though
various people (me included) have pondered issues like supporting
multiple Host Identities within a multi-user host etc.

> *  The SPIs needs to be encrypted. It provides limited user traffic

Definitely not.  Here I (and I guess a number of other people)
disagree strongly.

HIP has been explicitly designed to be middle box friendly, which
IKE (including IKEv2) is not.

>         HIP-TRANSFORM /* with list of DH groups */

Responder could select a suitable pre-computed R1 from a pool,
using the suggested D-H?  Adding optional HIP-TRANSFORM here
might be a good idea.  Or even make it mandatory, for simplicity's
sake?

I don't understand the need for the I1 nonce.  To remove the
need for R1 signature?

Didn't we discuss that before?  Anyone remembers the conclusions
or cares to dig up the archives?

>                                ID protection from passive attacker is

Maybe, but IMHO not now.  Something to remember for the next revision.

See Jukka Ylitalo and Pekka Nikander,  "BLIND: A Complete Identity
Protection Framework for End-points",  to appear in Security Protocols,
Twelfth International Workshop,  Cambridge, 24-28 April, 2004.

>                 any advantage over just encrypting the HMAC with 

You forget middle boxes.  If you have the signature, there is no
explicit benefit from the HMAC.  If the responder knows the initator's
identity, it can verify the signature before constructing the D-H keys.

> I think more people need to read this draft before the Last Call.

I strongly concur.

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Sep 2004 15:57:48 +0300 (EEST)

> what were the thoughts about this.  Anyone?

See the "DH Group selection " thread from:

http://honor.trusecure.com/pipermail/hipsec/2003-December/thread.html

To summarize, it is theoretically possible to negotiate two different DH
group selection, but in practice this may be difficult. As a consequence,
we negotiate only one DH group.

Since we are negotiating of a single DH group, either party has to suggest
the groups and the other has to accept one of them. HIP is designed to
protect both the initiator and the responder from various kinds of
attacks, but the emphasis is still on protecting the responder, IMHO. As a
result, it is better for the responder to be the party that is allowed to
make the suggestion to avoid initiators from overloading busy servers with
overly large DH groups.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Yogesh Prem Swami <[email-masked]>
Date: Mon, 13 Sep 2004 14:17:54 -0500

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:

> 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.

> 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.)

> 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.

> in the process of issuing -07.  -05 may be easier to read, if you

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.

> DoS protection.  However, it is considerably more complex than the

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.]]

---

From: Yogesh Prem Swami <[email-masked]>
Date: Mon, 13 Sep 2004 14:18:59 -0500

2nd e-mail.

> is just a convenient shorthand.

I strongly disagree with this. Let's backtrack a little bit here. In the
past (and present) we have used the socket quadruple to demux different
connection. The assumption was that the quad will not change after
connection setup. With mobility and multi homing, the IP address change,
so we need a new mechanism to demux different connections.  You are
achieving this through SPIs. (Note also, that the HIT flipping as
defined  in the draft is also not essential. Keeping it there might
still be a  good idea, if you don't want to change your TCP code, but
it's not  needed, in principle. The connection is already demuxed by the
time of IPsec processing, beyond which you only need to look at port
numbers.)

So the first issue is demuxing. That is, how do I demux different
connections, if my IP address keeps changing.

The second issue is how do I maintain this binding between the demux
numbers (i.e., SPI in this case) and the present IP address of the host.
This issue  is completely separate from the choice of using an SPI, or a
new IP option or what have you.

HIP base, to me seems like a protocol for manging this demux binding. If
you were to propose a new protocol type that will be carried in every
packet (just as SPI) for the purpose of demuxing (and I would have
preferred that over ESP), I wouldn't have complained. But I strongly
disagree that the management of demuxing numbers should be given a
protocol type and should be mixed.

I would like to listen from other people on what they think.

> Actually not.  You can easily implement 99% of HIP on user level.

If you're going to implement in user level, then just use UDP. Isn't that
the reasons why UDP exists?

Also, if you want to support multicast using HIP, you will need yet
another  key exchange--substantially different from HIP key exchange.
Are you  proposing to use another protocol-type for multicast key
exchange.  (Also, in case of multicast, one key exchange might not fit
all use  cases, so you will need a lot of protocol types if you want to
do it at  IP layer. And yes, you can multiplex all of them on the same
protocol  type, but then it will be my turn to cry the complexity wolf.
:-) )

> The rest of your disadvantages don't apply once you realise this.

To me, architecturally it seems cleaner to keep the SA management (i.e.,
3.5 layer management) separate from the 3.5 layer itself. HIP key
exchange is a 3.5 layer manager, and there is no need to mix it with the
3.5 demuxing layer itself--which you achieve through SPI.

> opinion is not clear enough.

Well the arch document doesn't say anything about this either. Am I
reading the right draft:
http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-06.txt?
Isn't this draft in RFC queue right now?

--Yogesh

---

From: Yogesh Prem Swami <[email-masked]>
Date: Mon, 13 Sep 2004 14:19:34 -0500

3rd.

> You can vary the cookie difficulty.  There is nothing wrong in

Right, but you still loose a Round Trip.

> possible, not to optimise it for any specific use case.

Well, considering a DoS attack is an optimization, isn't it?

> Ever heard about TCP SYN flooding? :-) That is a real problem, even

Never heard of it, really. Aha! Did the Babylonians face this kind of
flooding? :-))

You removed the text below message 2 and changed the meaning
completely. I was suggesting that if the responder *perceives* an
attack,  only then it should trigger  the cookie/puzzle mechanism. If
not, there is no need to waste a round trip. Here is the text from my
previous message.

""

          3.  I->R:   HIT-I, HIT-R, encrypt_with_g^ir_/_random_key{HI-I,
                      USER_ID-I, SPI-I} HMAC, SIG-I
                      private_key{random_key}

""

But I understand that you design goal is to let the responder select
the right group etc., and that might interfere with what I am proposing.
Which choice is better is debatable, though.

--Yogesh

---

From: Yogesh Prem Swami <[email-masked]>
Date: Mon, 13 Sep 2004 14:21:04 -0500

4th, and last! I promise.

> what were the thoughts about this.  Anyone?

I read Mika's comments and the old discussion, but I still think it's
useful to put HIP-TRANSFORM in I1. It's possible that the Initiator and
Responder both consider a certain group to be safe, but the default
choice on the two sides could be different. In those cases, HIP-XFRM in
I1 will help. Also, just because I1 proposes a HIP transform, Responder
doesn't have to accept it (so there is no chance of attacker degrading
the quality of SA). It might send it's own choice anyways
(falling back to the present scheme, to some extent.)

> I don't understand this comment.  Please elaborate.

Okay, may be I misunderstood, so let me ask a question. Let's say I want
to have 3 different SA between same  hosts at the same time (because my
local policy requires on 1 SA per TCP connection and all three TCP
connections start at once.) How does HIP disambiguate between these
three parallel ongoing key exchange. Does it mean SA creating should be
sequential. I guess this is what you mean by coarse granular key
exchange for HIP, right? Some text in either of the two drafts
(base/arch) will help.

> the Responder hasn't got any state when it gets I2.

Wow! back up a little bit. When Initiator receives R1, it can compute
the session  key. If you want to follow the design choice of sigma, you
should  provide a proof of possession of the ephemeral key by the HMAC,
not just  the signature as it is in the draft right now.

But then, this makes me ask another question. How does the Responder get
the public-key of the Initiator. If it's from DNSSec, then it's useful
to use HMAC. If not, then why bother--you are anyway willing to risk
identity mis binding.

> Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO 2003: 400-425

I disagree that the present key-exchange is based on SIGMA. That was the
whole point of my question for a reference :-)

> Not necessarily.  With large K, solving the puzzle takes a lot of CPU.

This is unnecessary protection, IMO. Also, what is the order of
processing for these messages, i.e., do you fist verify the signature or
compute the solution. If you verify the signature first -- as you
should -- then aren't you opening up to some kind of DoS? Note that a
counter (R1_COUNTER) doesn't help because a smart blind attacker can
just send a value in the upper quarter of the number space with high
probability of success, so the  primitive sequence number check before
signature verification will not help much.

> Good point.  Please elaborate so that we understand better, I haven't

One way to get rid of the signature in R1 is to consider all R1s as a
valid response. Since only a valid Initiator can provide an R2 (because
of HMAC), its safe to delete the other invalid R1s after the key
exchange is completed. IKEv2 draft does a better job than me in
explaining these things ... so please see that.

> Suggested text to be added?

You might want to check JFK paper (Steve Bellovin, et. al. "Just Fast
Keying) on r caching.

> complexity.  HIP is a _Host_ Identity Protocol, after all, even though

No. That's not what I meant. In the draft you refer to e-mail address,
FQDN, etc as HOST_ID (you need these for polices, right?). This is
confusing and it should be renamed USER_ID, IMO. Also adding an OPAQUE
field there doesn't add complexity--or maybe this time I am "blind." :-)

> Definitely not.  Here I (and I guess a number of other people)

I can live with a clear SPIN--although it does make traffic
confidentiality little worse.

> IKE (including IKEv2) is not.

Well IKEv2 does not have any problems (or it's being fixed) with middle
boxes to the best of my knowledge.

> I don't understand the need for the I1 nonce.  To remove the

But also to allow parallel SA creation. May be you don't want to
consider in the design choice.

> Twelfth International Workshop,  Cambridge, 24-28 April, 2004.

Sure. Thanks.

> identity, it can verify the signature before constructing the D-H keys.

Agreed, but on the other hand, HMAC is more resistant to attacks due to
HASH collision. With SHA0  nearly colliding, and MD5 gone, my
confidence in SHA1 is very low. But HMAC-SHA (or MD5 for that matter)
is still relatively secure.

So much form me! Hope this is useful discussion.

Thanks
Yogesh

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Sep 2004 13:56:41 +0300

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

> achieve something similar. I think we should learn the right lessons

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.

> 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.

> (i.e., present HIP) when another one already exists.

Ok, I will add a section on this.

> 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.

> 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.

> why? IESG might as well ask the same question.

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

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Sep 2004 14:02:55 +0300

> Well, considering a DoS attack is an optimization, isn't it?

No, it is a fundamental property of the base design.
DoS protection is taken into a new level in Hi3, and wouldn't
be possible without this base DoS protection.

> completely.

Sorry about that.

> I was suggesting that if the responder *perceives* an

There is no extra round trip in the typical case.  See my separate
message, next.

> Which choice is better is debatable, though.

Sure it is debatable.  OTOH, an attacker can choose when to play
Initiator.  If it wants to play Responder, it has to wait.
That's the rationale behind our choice.

--Pekka

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Sep 2004 14:03:19 +0300

FWIW, I agree with Pekka that the goals of HIP and IKEv2
are sufficiently different that they deserve their own
protocols.

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Sep 2004 14:31:44 +0300

> achieving this through SPIs.

No, we are not achieving this through SPIs.  We are achieving this
through using the HITs in the socket and the pseudo-header, as
Tom already wrote.

There rest, like using SPIs as a shorthand, is details, and not
important from the highest architectural-level point of view.

The rest of your argument doesn't hold, as it looks at the situation
from a very different point of view.  While your viewpoint is true
for many of the current implementations, it misses the architectural
change.

> exchange.

Of course not.  There are more than enough space for extensions
in the current HIP protocol.

> And yes, you can multiplex all of them on the same protocol
> type, but then it will be my turn to cry the complexity wolf.

I still hold the opinion that architectural complexity is well
measured by the number of LOC needed to implement it.  (With
some caveat emptors, of course, like not accepting ugly code.)

As you add more features, you need more code.

If your new protocols can benefit from existing infrastructure,
in a clean way, then you can save in terms of LOC.  In other
words, I don't buy you argument that implementing different
kinds of control protocols within a layer 3.5 control protocol
is necessarily bad design and leads to complexity.  Using
TCP or UDP demuxing may lead to architecturally worse complexity,
like necessitating built-in port based policy rules.

> 3.5 demuxing layer itself--which you achieve through SPI.

This is a fundamental difference in opinions.  Some people hold the
opinion that it is better to have separate control protocols and
separate data traffic protocols, like in the telephone networks.
Some people think that it is better to have in-band signalling,
like in TCP.  I guess my opinion is somewhere in the middle ground.
Especially, I think that Layer N signalling should not depend on Layer
N+K protocols for any K>0.  Consequently, Layer N signalling is
always either in-band at layer N, or directly at Layer N+1.

(You can read the comment above that IKE, with is use of UDP,
is badly designed.)

Another issue here is, again, middle boxes.  Having the control
protocol on a separate protocol number makes it easier to separate
data traffic and control traffic on a middle box.  No need to
look inside ESP, TCP or UDP, and therefore simpler fast path.

>>>     IKE is implemented on UDP for a good reason.

Out of curiosity, what are those good reasons?

> Isn't this draft in RFC queue right now?

-05 was, but was pulled back for a number of reasons.  The current
plan is to resubmit -07.

--Pekka

---

From: Yogesh Prem Swami <[email-masked]>
Date: Tue, 14 Sep 2004 16:24:44 -0500

Pekka-

Please see inline:

> important from the highest architectural-level point of view.

I understand this point. And I totally agree with you that keeping the 
SPI (or even HIT, if someone so wanted) in every packet is the right 
architecture. What I don't agree with is that the protocol that does the 
binding between the current IP address and a corresponding HIT should 
also be an IP protocol type.

I guess the difference in opinion is because in my mind, multiplexing 
connections and managing bindings are separate issues (and it might just 
be my tunnel vision). To me the present HIP key-exchange is a connection 
oriented protocol, unlike the traditional connectionless model of IP. So 
I am a little reluctant to mix the key-exchange 
(ip-to-hit-binding-management) with the actual packet processing (which 
I want to keep connection less). Note that the way ESP is designed, is 
connection less (even though aalmost all key exchanges, even for 
Multicast, will be connection oriented running as applications on some 
transport protocol).

I would like to keep the connection-less model of IP as it is, even 
after introducing the layer 3.5, and to me this means separating the 
binding management from the actual packet processing. Please note that 
this situation is very different from TCP, which is always connection 
oriented.

All that blah blah said, I think it's okay to gain experience using the 
present draft (i.e., IP as MUST as you want, and UDP as 
SHOUD/MAY/OPTIONAL--pick one). We can always come back during STD track 
discussion.

> for many of the current implementations, it misses the architectural

I guess the implementation viewpoint is just the reflection of present 
architecture. I like the present architecture, but I also like the ideas 
  of HIP. And I want both. :-)

> always either in-band at layer N, or directly at Layer N+1.

Please see above.

> Out of curiosity, what are those good reasons?

I guess I pointed that in first paragraph. The IPsec documents and IETF 
in general (if I can muster enough courage to say so :-) ) doesn't keep 
track of the design decisions. So I am just extrapolating what I 
understand ...

Another point that Steve Deering made during the IETF plenary session of 
August 2001 ( 
http://www.ietf.org/proceedings/01aug/slides/plenary-1/sld001.htm) was 
to look at Internet Protocols as an hourglass whose waistline is IP. 
There is advantage in keeping that waistline thin (and straight), IMO.

My rule of thumb: if its not related to routing, don't put it near IP 
(take it of leave it; I'm not going to argue either way on this. :-) ).

Yogesh

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Sep 2004 19:59:30 -0400

-----BEGIN PGP SIGNED MESSAGE-----

My recommendation is to finish the drafts as they are.

If there are still opportunities to steal IKEv2 concepts (i.e. packet
formats, traffic selector descriptors, etc.) for the current document,
do so. (I would have thought it was too late for that)

Were I implementing HIP in Openswan (which I wish I had resources to
do), I would likely write a seperate daemon, but turn many pieces of
pluto relating to PF_KEY, management, policy, etc. into libraries.

It would be nice if HIPv2 was simply a set of extensions to IKEv2(.1) 
that applied to IPv6 host-host use only.

I think we are among the few with feet in both the "managed insecurity"
camp, and the "opportunistic security" :-)

(Recently, we have been discussing how to use EAP and/or XAUTH to
"upgrade" an opportunistic connection to a "managed" one)

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 16 Sep 2004 10:38:51 +0300

>> No, we are not achieving [demultiplexing] through SPIs.  We are
>> achieving [that] through using the HITs in the socket and the
>> pseudo-header, as
>> Tom already wrote.
>>
> I understand this point. And I totally agree with you that keeping
> the SPI (or even HIT, if someone so wanted) in every packet is the
> right architecture.  What I don't agree with is that the protocol
> that does the binding between the current IP address and a
> corresponding HIT should also be an IP protocol type.

Ok.  I understand your stance, but disagree.  A perhaps major
source of my disagreement is that I don't consider HIP just as
a binding management protocol, but as a new, full layer.
But let's see...

> I guess the difference in opinion is because in my mind,
> multiplexing connections and managing bindings are separate
> issues (and it might just be my tunnel vision).

I don't quite understand what do you mean with that statement.
Reading further...

> To me the present HIP key-exchange is a connection oriented
> protocol, unlike the traditional connectionless model of IP.

Ah.  But by adding replay protection to IPsec you basically make
the whole IP layer to have state, i.e., connection-oriented.

Apparently we need to go into fundamentals.  For more on my
stance on this, see

Tuomas Aura and Pekka Nikander, "Stateless connections," in
proceedings of International Conference on Information and
Communications Security ICICS'97, Beijing, November 1997,
pp. 87-97, Lecture  Notes in Computer Science 1334, Springer
Verlag 1997.

Trying to summarize some of the thoughts in that paper, the basic
difference between connection-oriented and connection-less
protocols is where the state is maintained.  The organization
of retransmissions is less relevant, as is congestion control.
They are different aspects, and almost orthogonal.

In a connection-oriented protocol you keep state on both ends.
(According to this classification, a bound UDP socket is
connection-oriented.)  In a connection-less protocol you
typically keep state only at the client/initiator/whatever end,
or at neither end.  In the latter case the state is typically
kept at the higher protocol layers.

In traditional IP, all state is at upper layers.  The only state
that IP needs to keep is the routing state.  Especially, there
is no state associated with a given peer IP address.

This all changes with the introduction of IPsec, and especially
when you apply replay protection.  Then you have to keep state
per peer address, including the session keys AND the replay counter.

 From this point of view, making the HIP control protocol something
that is more or less parallel to ICMP is the right choice.  (This
stance is strengthened with middle-box considerations.)

> So I am a little reluctant to mix the key-exchange
> (ip-to-hit-binding-management) with the actual packet processing
> (which I want to keep connection less).

Well, that is not mixed, currently.  In effect, you are now
arguing that instead of allocating one protocol number, we should
allocate two:  one for HIP control traffic, and the other one
for HIP data traffic.  The fact that we are using ESP for the
latter _is_ problematic, but currently it is the best we can
easily do without allocating yet another protocol number.

> Note that the way ESP is designed, is connection less

But it is not :-)  Already the keys create a kind of peer-to-peer
connection, and that is made much stricter and stronger with
the introduction of replay-protection counters.

> (even though aalmost all key exchanges, even for Multicast, will be
> connection oriented running as applications on some transport 
> protocol).

Remember my earlier comment about the relationship between a control
protocol and the corresponding payload protocol?  I don't want to
repeat that.

Think about parallels in modern design:
- ICMP runs on the top of IP, which it controls.
- SIP runs on the top of UDP, which it typically controls.
- HTTP control is in-band.
- SCTP and TCP control is in-band.
- most routing protocols run on the top of IP, which they control

Hence, the majority of IP world control protocols seem to run either
directly on the top of the protocol that they control, or in-band.

The notable exceptions are IKE and some routing protocols.  In the
routing protocols' case TCP is used for retransmissions.

 From an architectural point of view, I consider the IKE case
especially problematic, as it requires a specific exception to
the default IPsec policies in order to allow IKE to get through.
Such exceptions make any architecture less beautiful.  (Read:
I still think that some aspects of IKE stink, even with IKEv2.)

In summary, to me it is almost impartial whether the future
HIP will be based on a single protocol number, where both the
control and data protocols share the same protocol number,
or whether we use two protocol numbers.  What I am opposing is
moving the control protocol to an upper layer, where it does
_not_ belong.  I slightly favour two protocol numbers, as using
two protocol numbers makes it easier to separate control and
data traffic at middle boxes.

> I would like to keep the connection-less model of IP as it is,
> even after introducing the layer 3.5, and to me this means
> separating the binding management from the actual packet processing.

I don't have anything against separating the control protocol
(your binding management) and the data protocol (your packet
processing).  That is what we effectively do today.

What I am opposing is the idea of unnecessarily inserting another
protocol between the control protocol and the data protocol.
That opposition is purely architectural, as I have written a
number of times.  Practical matters weight otherwise, and as I
have written, if people want to write a HIP-over-UDP draft, I will
be in favour of accepting it as a WG item.

> I think it's okay to gain experience using the present draft
> (i.e., IP as MUST as you want, and UDP as SHOUD/MAY/OPTIONAL--
> pick one).  We can always come back during STD track discussion.

Agreed other than that if there is UDP, it should be OPTIONAL,
or at most SHOULD implement, MAY use, default use being IP.

> I guess the implementation viewpoint is just the reflection of
> present architecture. I like the present architecture, but I
> also like the ideas  of HIP. And I want both. :-)

You want the benefits but not the drawbacks. :-)  How nice. :-)

More seriously, for me the new architecture that HIP presents
is much more important than the features it gives.

> ... I am just extrapolating what I understand ...

Still, it would be nice to explicitly hear what you understand
so that I can rip it down and tear in pieces :-)

> Another point that Steve Deering made during the IETF plenary
> session of August 2001 was to look at Internet Protocols as an
> hourglass whose waistline is IP. There is advantage in keeping
> that waistline thin (and straight), IMO.

I was there.  Many people think that it is time to move that
waistline on the top of IP (or around IPsec), which is exactly
what HIP is doing.  (The motivation for moving the waistline
up is that we currently have two waists, IPv4 and IPv6.)

> My rule of thumb: if its not related to routing, don't put it
> near IP (take it of leave it; I'm not going to argue either
> way on this. :-) ).

The current IP has much more than just routing.  IPsec is a
main culprit (if not the main culprit) for that.  Based on your
argument, we should get rid of IPsec and use TLS.

The "lower" part of IP, which implements routing, fragmentation
and few other things, is fine and dandy.  It is the upper,
host-specific part of IP which has become bloated and ugly.
If I was to blame a single party, I would point to the VPN and
IPsec gateway folks in the IPsec WG, and Paul Francis for inventing
NAT.  But that would most probably be unfair.  More seriously,
I think that the current situation results from too little
direction from the IAB and too little architectural house-keeping
from the IESG members.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 16 Sep 2004 10:43:06 +0300

> do so. (I would have thought it was too late for that)

I don't think we would like to steal IKEv2 packet formats, because
IMHO our packet format is slightly better.  We don't need to steal
traffic selectors, as we don't have them.  (If someone is to write
a traffic selector extension to HIP, it would be nice if they used
IKEv2 compatible mechanisms.)

What we should do is to fix HIP to be SIGMA compliant.  I asked
Yogesh to make a write-up for that, as he seems to be a better expect
in that aspect than we are.  But he hasn't answered whether he will
do that or not, or at least I haven't seen any indication from him
in that respect.

> pluto relating to PF_KEY, management, policy, etc. into libraries.

Sounds pretty much how we've implemented HIP for FreeBSD.  BTW,
our user level parts now compile on Linux, too.  They don't run,
as we don't implement NETLINK support and Linux doesn't implement
the necessary PF_KEY extensions.

> that applied to IPv6 host-host use only.

Agreed other than that I don't understand your reference to IPv6.
HIP supports quite nicely IPv4, both at the API and especially
as a packet transport.

--Pekka

---

From: Yogesh Prem Swami <[email-masked]>
Date: Thu, 16 Sep 2004 11:37:04 -0500

Hi Pekka,

> do that or not, or at least I haven't seen any indication from him

I will do this sometime next week (and reply to a few e-mails in the 
same time frame). Sorry about not replying to those e-mails earlier (I 
got caught up with some other work).

Thanks
Best Regards
Yogesh

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Sep 2004 10:14:56 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    >> If there are still opportunities to steal IKEv2 concepts

    Pekka> I don't think we would like to steal IKEv2 packet formats,
    Pekka> because IMHO our packet format is slightly better.  We don't

  I was pretty sure it was too late for such a thing anyway :-)

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Sep 2004 09:08:40 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> It would be nice if HIPv2 was simply a set of extensions to
    >> IKEv2(.1) that applied to IPv6 host-host use only.

    Pekka> Agreed other than that I don't understand your reference to
    Pekka> IPv6.  HIP supports quite nicely IPv4, both at the API and
    Pekka> especially as a packet transport.

  I realize this, but I the places where I think HIP will be easily
adopted are IPv6 situations.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Sep 2004 16:33:03 -0400

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Sep 2004 16:33:07 -0400

---

From: Yogesh Prem Swami <[email-masked]>
Date: Sun, 19 Sep 2004 16:08:47 -0500

<text removed>
> changes that are needed to make HIP to be based on SIGMA.
<text removed>

Okay, the minimal changes required in the present HIP key exchange is
to just add a HMAC(g^xy, HOST_ID) in message-3 and adds HOST_ID in
the HMAC of message 4 (shown in the message exchange below). Note
that the present protocol in the draft looks fairly secure, but as SIGMA
paper points out encryption is not the right method to prove possession
of session key (but the attack that the paper describes in the presence
of stream cipher doesn't apply here). So while the encrypted token
{ PUBLIC_KEY-I, Domain-ID-I }_g^ri and the signature over this token
guarantees that identity mis-binding attack cannot be carried out,
it's still better to use HMAC, IMO. (Besides we have a proof that
HMAC based scheme is secure.)

I have also added nonce-I and nonce-R in all these message. This is
important to allow parallel SA creation, and allow cases where both
initiator and responder choose pre computed g^i and g^r (this can
happen, unless the draft explicitly prevents it). The nonce should
be used in deriving the session keys.

So the key exchange with minimum change should look something like:

1. I->R: NCN-I, 0, HIT-I, [HIT-R]

2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R
          SIG( HIT-R, g^r, PUBLIC_KEY-R)

3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i,
          { PUBLIC_KEY-I, Domain-ID-I }_g^ri,
          SIG( HIT-I, HIT-R, SPI, g^i,
          { PUBLIC_KEY-R, Domain-ID }_g^ri, )
          *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)*

4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I),
          HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content
                                                   has changed */

o  In the draft it's important to say that the responder should keep
    the random value r for at least 2*MSL  (and possibly longer) from the
    last time it sent message 2. In case Message 3 arrives after 2*MSL,
    and no random number r can be found, it should be dropped and an ICMP
    message should be sent. If the Initiator receives an ICMP after
    sending message-3, it should not assume that the responder sent
    the message, and should not close that session. An Initiator
    MAY however start with a new parallel I1 with a new nonce value.

Couple of observations about this key exchange:

A) The identity of Responder cannot be concealed even against the
    passive attack. The HOST_ID in message-2 is required so that the
    Initiator can get the public-key to verify the SIGNATURE from
    responder.

B) The identity of Initiator cannot be concealed against an active
    attacker unless g^r is covered in SIGNATURE calculation in
    message-2. (So keep section-7 description and change section-4 text)

(A) and (B) together means that if we want to get responders ID
protection then we need to severely reorganize the messages.
One simple thing one can do is to only send the public-key and
in message-2 (and leave Domain-ID-R field completely out). Later,
Responder can put Domain-ID as encrypted in message-4 and let Initiator
verify it against the MAC received in message-2. The advantage is that
we can now protect the identity of Initiator against passive attacker
and the Identity of responder against Active attackers. The disadvantage
is that the Initiator's ID cannot be protected against active attackers.
Also, the HOST_ID packet format will have to be changed.

Note that protecting the Public-Key alone without Domain-ID is not
that useful. The worst thing that an attacker can do by stealing the
public key is to register it under her own name (i.e., Eve takes
Alice's public key and puts it in DNSsec under Eve's name, assuming
DNSsec doesn't do proof of possession checks). But the HMAC binding to
name in  SIGMA prevents from attacks that can result from this kind of
behavior,  so it's not that useful to protect the public-key. Note that 
this is the reason I have added HOST_ID in message-4. HMACing only HITs 
will get us in trouble.

Yogesh