Subject: Re: [Mip6] Justifications forstandardizingdraft-ietf-mip6-auth-protocol-00.txt

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Sep 2004 00:31:32 +0200

In your previous mail you wrote:

   Francis Dupont wrote:
   
   > => I agree, manual keying is not really usable.
   
=> by "really" I meaned "in the real world for general deployment".

   This is way over the top.
   
   Manual keying is obviously usable.  People
   use it today.  It's easy.
   
=> I disagree: it is not easy and it is even difficult between
different implementations. Even pre-shared secret can be hairy!

   There is a lot of understanding about its
   limitations.  I could understand it if you
   would say,
   
   "Manual keying doesn't work when ..."
   
   or,
   
   "Manual keyong only works when ..."
   
=> it works but it is not easy to setup in the real world and
it is essentially insecure (exactly for the same reason it doesn't
provide anti-replay protection).

   or any one of a large number of reasonable
   statements.  But to say it is not really
   usable is just plain wrong.
   
=> I believe you don't understand what I've meant.

   And, I would like to also mention, it is
   pretty simple and appropriate for the scenarios
   where it does work.

=> IMHO the only scenario is in the labs...

   Sometimes it seems to me
   that such value does not receive due respect
   in security arguments.  Just because a solution
   doesn't cover all of the cases doesn't mean it
   is a kludge or is unusable.
   
=> I can't believe you suggest to use manual keying in a commercial
service... Obviously I don't understand what you mean.

Thanks

[email-masked]

PS: I don't joke about pre-shared keys: I had the bad idea to use quotes
in a config file. And this kind of things is really (argh, I use again
this word :-) hard to debug!

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 21 Sep 2004 16:21:05 -0700

Hello Francis,

> different implementations. Even pre-shared secret can be hairy!

Do you mean manual keying for ...?IPsec?...
...Mobile IPv6?...   or what?

> provide anti-replay protection).

Your statement was _VERY_ general.  So, for instance,
in systems where replay protection is already provided
by some other means, this isn't a problem.  Say, for
instance, Mobile IPv6 in many scenarios.

Plus, ease of setup is largely a function of
the user interface, so I claim it's not at all
relevant to the validity of your original
too-broad statement.

> => I believe you don't understand what I've meant.

That's always a possibility, but up until now I
thought I did -- except that you didn't state
the restrictions which eventually would cause
your statement to become true.

> => IMHO the only scenario is in the labs...

Are we talking in general, or about Mobile IPv6
products...?

If in general, then I suggest that most password
based systems are "manual keyed" systems.  In fact,
they often have manual key refresh, which of course
nobody loves.

If only about Mobile IPv6 products, then I cannot
show you the commercial product that uses manual
keying so I have to yield the discussion.

> service... Obviously I don't understand what you mean.

I think one could make a lot of money in a
commercial service by selling such systems,
and that they could be targeted towards uses
in which they would be plenty secure enough,
and the customers would be delighted.  If you
include password-based systems that are not
necessarily meant to be used with Mobile IPv6,
then naturally people already make a lot of
money on those.  I am pretty sure I could
desgn a manual-keyed system even for Mobile IPv6
that would solve the user-interface problems.

It depends on how _broadly applicable_ the
solution has to be.

> this word :-) hard to debug!

First, your example shows the fallibility of poor
user interfaces.  Second, I never claimed that
manual keying is universally simplest.  Third,
your example again doesn't show the downside of
manual keying, it shows that it's nice to be able
to debug what the key is if it's done manually.

Cordialement,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Sep 2004 09:42:32 +0200

=> manual keying for IPsec, in any context including the Mobile IPv6 one.
The pre-shared secret allusion is about IKE.

   > provide anti-replay protection).
   
   Your statement was _VERY_ general.

=> yes, the reason is intrinsic so the consequence is general.

   So, for instance,
   in systems where replay protection is already provided
   by some other means, this isn't a problem.

=> the replay protection issue is a consequence. My argument is the long
term use of a shared secret is essentially not a good thing, specially
with mechanisms which are not designed for it.

   Say, for instance, Mobile IPv6 in many scenarios.

=> IPsec (AH or ESP) is a good example of a mechanism not designed for
a long term shared secret. Counter mode is an extreme example.
   
   the user interface,

=> I agree and I've never found a manual keying user interface that
one can say it is user friendly...

   so I claim it's not at all
   relevant to the validity of your original
   too-broad statement.
   
=> I don't understand why you insist.

   
=> in general

=> yes but password systems have more issue, specially
about the real secret length. On the other hand they are designed
for long term shared secret, for instance they don't use
the password directly as a key, they derive session keys
with it using mechanisms where the shared secret is protected
(unfortunately here I describe more an ideal system than
a real world one :-).

=> the last point (be plenty secure enough) is where our opinions
diverge, specially about what means "enough".

   design a manual-keyed system even for Mobile IPv6

=> by "really" I meant anywhere on the Internet.
   
Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 Sep 2004 17:07:01 +0200

I've heard that my comments about IPsec manual keying were interpreted
as against pre-shared secret for routing optimization. This mechanism
was carefully designed to avoid the usual weaknesses of long term shared
secret, in fact, IMHO it is very clear that it is far better than a
manual keyed IPsec security association pair for the same use (protection
of MIPv6 signaling in the routing optimization case, i.e., between the
mobile node and a correspondent node).

Ref: draft-ietf-mip6-precfgKbm-00.txt
PS: and of course it is far better than the return routability procedure!