Subject: RE: New multi6 draft: WIMP

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Sat, 14 Feb 2004 19:44:24 -0600

>> We have submitted a new multi6 draft to I-D directory. The draft 
>> defines a Weak Identifier Multihoming Protocol (WIMP), and 
>we wrote it 
>> in order to see how opportunistic/weak authentication 
>methods could be 
>> used to sove the multi6 problem.
>
>Ok. This is basically a secure negotiation mechanism.

This is basically a _weak_ secure negotiation mechanism. It would 
be better if the authors state explicitly the environments it will
be used. If I am running an enterprise internet service which is 
site-MHed for reliability, I won't prefer HIP or WIMP or PBK for 
secure negotiation. They are useful but only for certain limited 
scenarios. 

while HIP depends on a trusted model like DNSSEC, why it does extra 
work (crypto puzzles) to avoid third party infrastructure? what is 
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?

btw, is their any standardized RFC supporting weak authentication 
methods? RFC 1984 states explicitly that IETF won't knowingly make
the protocol weaker. But, it was wrote for a different purpose. 
anyway, I wish that authors of HIP/WIMP explicitly state the 
environment in which weak authentication is ok.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Feb 2004 10:19:17 +0200

Senthil,

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

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

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

> 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: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 10:50:57 +0200

> environment in which weak authentication is ok.

Pekka already pointed to an paper myself and him. But I'd like
to add that while we perhaps introduced the term, there are in
fact some schemes like that in existing protocols. For instance:

o SIP (RFC 3261) uses a leap-of-faith scheme where two callers
   can learn their public keys on the fly and register them for
   secure communications for later.

o SIP also offers a null authentication challenge-response
   scheme, which can be used to assure that the peer at least
   has a valid address.

o Mobile IPv6 (in RFC ed queue) uses a weak authentication
   technique in its "RR" mechanism that protects route optimization
   binding updates.

o SSH uses leap-of-faith when contacting the server for the
   first time.

o ...

Anyway, maybe the term "weak authentication" is a bit misleading. We
originally used it a little provocatively. But really, the question
is not about strength as much it is about the type of authentication.
It has been demonstrated in many contexts that "strong" authentication
based on some credentials may not actually match at all the requirements
of a specific application, and may in fact be less secure than other
types of authentication better suited for the application at hand. 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?

--Jari

---

From: Jukka Ylitalo <[email-masked]>
Date: Mon, 16 Feb 2004 12:35:33 +0200

>secure negotiation. They are useful but only for certain limited 
Using WIMP and HIP, it is possible that routers rewrite source locators. 
However,
either of the drafts does not explicitly mention that.

Basically, we have several promising protocol proposals, each of them
emphasizing different issues in the protocol design. Basically, the 
multi6 proposals
can be divided into two dimensions. The best solution migth be somewhere 
in the
middle of the axis.

In the first axis, there are  protocols  that  do not  directly 
co-operate with the
routing protocols, or middle-boxes. The protocols are implemented at the
end-hosts. On the other end of that axis, there are protocols having 
"build-in"
public key based security, including encryption and  integrity 
protection, like HIP does.
The opposite end of the axis contains protocols, like MAST, that basis
their security finally on, e.g., IKE.  WIMP lies in the middle, offering 
so called weak
"build-in" security properties.

The second axis of coordinates consists of protocols that co-operate 
with the
routing protocols. The protocols require changes in the site-routers, and
optionally in the global routing tables.

 From the WIMP point of view, an attractive combination would consist
features of  MAST, NOID,  SLAP, HIP and WIMP.

>him to waste his CPU cycle?
Pekka N. already answered these questions.

>environment in which weak authentication is ok.
Weak authentication gives protection against several re-direction 
attacks. At the
same time it does not consume much CPU time.  WIMP does not offer 
encryption,
but a limited integrity protection against MitM attacks. When a server 
does not
require public key or pre-shared secret based authentication, but is 
worried about re-direction attacks, WIMP is a good candidate.

Br, Jukka