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

[[e-mail] (Pekka Nikander)]

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.