[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New multi6 draft: WIMP
Ayyasamy, Senthilkumar (UMKC-Student) wrote:
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.
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.
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?
Pekka N. already answered these questions.
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.
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