Subject: [Hipsec] About the HIP security model (was Re: New multi6 draft: WIMP)

From: [email-masked] (Pekka Nikander)
Date: Mon Feb 16 02:37:00 2004

Senthil,

> while HIP depends on a trusted model like DNSSEC, why it does extra
> work (crypto puzzles) to avoid third party infrastructure?

The Security Considerations section in the HIP architecture
document (currently draft-moskowitz-hip-arch-05.txt) tries to
explain this.  If it fails, I'd like to get feedback; there is
still time to fix that before the draft goes to RFC.  Hence,
I please read and comment that section.

In particular, HIP does not include the crypto puzzle in order
to *avoid* third party infrastructure.  It does that in order
to block a DoS attack where an attacker makes the Responder
to make expensive crypto operations (D-H shared key generation
and DSA verification) just by sending garbage keys to the Responder.

> the incentive to use such schemes? Although, crypto puzzles work
> against intruders, are we not penalizing a legitimate user by asking
> him to waste his CPU cycle?

Unfortunately you cannot avoid such "pay-first-something" schemes
in an open network.  You don't know whether the Initiator is
a legitimate user or a DoS attacker before you check the signature.
Unfortunately, checking the signature costs CPU, and therefore it
makes sense to ask the user to "pay", or show that it is sincere,
by burning some CPU *first*.  In other words, you raise the bar for
DoS attackers, by slightly penalizing legitimate users.  Furthermore,
in HIP you can adjust how hard the puzzle is.  Hence, as long as
you work under normal conditions, you can make the puzzle very easy
to solve.  As soon as you start to see load, you can change over to
a scheme where solving the puzzle requires more CPU.

See, e.g., the following paper, for more information.

Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo,  "DOS-resistant
Authentication  with Client Puzzles,"  in Christianson, Malcolm,
Crispo, and Roe (Eds.)  Security Protocols, 8th International
Workshop,  Cambridge, UK, April 3-5, 2000; revised papers, LNCS
2133, pp. 170-177, Springer 2001.

> btw, is their any standardized RFC supporting weak authentication
> methods?

My understanding of "weak" authentication is that the whole
area is pretty new.  In fact, it looks like that we launched
the term in our paper a couple of years ago:

Jari Arkko and Pekka Nikander,  "How to Authenticate Unknown
Principals without Trusted  Parties," to appear in Proceedings
of Security Protocols Workshop  2002, Cambridge, UK, April 16-19,
2002.

Mobile IPv6 RO depends on a "weak authentication" method, RR.
Other than that, I don't know, but I may be just ignorant.

> anyway, I wish that authors of HIP/WIMP explicitly state the
> environment in which weak authentication is ok.

draft-moskowitz-hip-arch-05.txt tries to discuss this form
the HIP point of view.  Again, if you find that discussion
lacking or confusing, please let me know in which ways.  If
you could suggest improvements, that would be even better.

--Pekka N.

---

From: [email-masked] (senthil ayyasamy)
Date: Tue Feb 17 09:58:02 2004

At 02:50 AM 2/16/2004, you wrote:
>In HIP, its about the ability to bind all communications to the host
>identity. This is different, but not at all weaker than authenticating
>all nodes to some security infrastructure. For instance, I might be
>able to prove that I am [email-masked], but does that entitle
>me to grab all communications destined to <an example address> at IP
>layer?

I am not able to follow your example. But, from a routing perspective,
origin and path validation is the basic security requirement. I should
be able to prove that a particular AS is allowed to announce a block
of prefix (delegated according to the address allocation policy.) In
this case, how HIP identity will be able to self-certify? It doesn't
have enough information to prove address space ownership(a PKI/CA-web
of trust model is necessary.) This is the only way to avoid address
space thefts.

---

From: [email-masked] (Julien Laganier)
Date: Wed Feb 18 01:37:00 2004

Hi Senthil,

Please find some thoughts included below,

On Tuesday 17 February 2004 16:35, senthil ayyasamy wrote:
> this case, how HIP identity will be able to self-certify?

HIP identity self-certify as a regular public-private key pair. If someone 
claims to have a given public key, nobody can pretend to have the same public 
key unless he knows the corresponding private key; so by keeping your private 
key, you make your public key self-certifying (same things for self-signed 
certificates). The same applies to the HI which is a mere public key

> It doesn't

If you generate your HI, nobody can steal it. Then you hash the HI into your 
128bit HIT. An attacker wanting to steal your HIT would need to generate a 
public-private key pair that hash to the same HIT, and it doesn't appear to 
me as an easy task because it's somewhat equivalent to reversing the 
_one-way_ hash function.

Thanks,

--julien

---

From: [email-masked] (Jari Arkko)
Date: Wed Feb 18 02:57:00 2004

> me as an easy task because it's somewhat equivalent to reversing the 

I agree with Julien on the above.

Also, I'd like to ask you Senthil more about what you mean by
address space ownership.  If you mean host address ownership, I think
it has been demonstrated many times in the past that PKI or web
of trust is not at all suitable for that. Or does your personal /
host certificate say something about the IPv6 addresses you can
use? (If you have a cert; most people don't.) I thought so...

And in HIP, we don't really need to show address ownership because
all communications are tied to the HI/HIT. It is only necessary to
show ownership of that.

On the other hand, perhaps you are referring to some other property
than host address ownership. Perhaps ownership of an address block
by an access router or a border router? For that, PKIs may be useful,
SEND, for instance, provides an optional capability for this using
certs and I think there was also some BGP feature that made use of
the same style of certs. But I'm not sure what address block ownership
would have to do with HIP or MULTI6 problems. Perhaps you or someone
else can clarify that to me.

--Jari

---

From: [email-masked] (senthil ayyasamy)
Date: Wed Feb 18 06:20:01 2004

At 10:37 AM 2/18/2004 +0200, jari arkko wrote:
>>If you generate your HI, nobody can steal it. Then you hash the HI into 
>>your 128bit HIT. An attacker wanting to steal your HIT would need to 
>>generate a public-private key pair that hash to the same HIT, and it 
>>doesn't appear to me as an easy task because it's somewhat equivalent to 
>>reversing the _one-way_ hash function.
>

I clearly see the benefit in coupling self-certifying identification
with its on-going communications. Also, I understand the limitations
of web of trust model for host identity. other than the documented
problems, PKI or CA doesn't satisfy usable security (cost/complexity)
requirements. For example, as a student, i should be able to deploy
a secure application system without wasting my money and also, not
depend on my university admins. Here, i can opt for HIP, instead of
cert+SSL.

But, by address space ownership, i actually meant address _block_
ownership; which is more than host identity. As you mention
below, i was thinking about BGP security (and what HIP has to
offer, as it provides authorization feature which IPsec lacks.)
But, as the name suggests, HIP can only help in validating the
"identifier" rather than "locator" claim. From a multi-homing
perspective, locator validation is very important (more on this
below.) btw, in my previous mail, i just meant to say, HIP is
not a replacement to PKI.

as a side note, weak authentication using hash chains can be
useful in detecting invalid routes. An Autonomous system will
hear more than single advertisement for the same destination.
So, WIMP like feature (reverse hash chains) can be used for
route consistency tests between those multiple advertisements.
but, i am digressing ;-)

>else can clarify that to me.

I agree, address block ownership has nothing to do with HIP or its
mobility extensions. But, it has more to do with site multi-homing.
Site multi homing is a legitimate case of multiple locator origin.
OTOH, MOAS (multi origin prefix) announcements due to intentional
attacks are very common. So, how we are going to differentiate
between a legitimate MOAS case (site multi-homing) and the
intentional MOAS case? Here, locator verification is important
than identifier verification. How HIP helps here? It needs S-BGP/
soBGP which depends on PKI/CA.

also, locator re-writing solutions not just introduce redirection
attacks but also, makes BGP AS path verification difficult. The
threat attack draft seems to be silent on network based attack
possibilities(it just extends MIP6 based attack scenarios.)

In short, locator authorization has routing related security
considerations which HIP cannot support.

>certificates). The same applies to the HI which is a mere public key

taking your statement at its face value, a MITM attacker can easily subvert
the initial exchange. but, yes, it can be avoided by a challenge-response
mechanism and HIP supports such a feature.

---

From: Erik Nordmark <[email-masked]> (Erik Nordmark)
Date: Thu Feb 19 01:34:01 2004

> possibilities(it just extends MIP6 based attack scenarios.)

Can you flesh out more about the types of attacks you think are
missing from the draft/discussion?

  Erik