Subject: Re: [mobile-ip] No keying for "weak" global authentication

From: James Kempf <[email-masked]>
Date: Wed, 26 Sep 2001 09:16:33 -0700 (PDT)

Jari,

Your recommendation below strikes me as one of the most sensible I've
heard in this entire debate. I have not been following this thread
intensively, but it seems to me like it should be possible to
come up with a standard that leaves room for newer key management
protocols that are more flexible, while also allowing known,
perhaps suboptimal protocols to serve in the interim. This opinion may
be naively optimistic, and it certainly not informed by a thorough
study of the problem, but I think it could be a tactic to get MIPv6
out of its current holding pattern, as long as the IESG agrees, of course.

		jak

>Date: Wed, 26 Sep 2001 13:01:21 +0300
>From: Jari Arkko <[email-masked]>
>To: Erik Nordmark <[email-masked]>, [email-masked]
>CC: [email-masked], [email-masked], "Hesham Soliman 
(ERA)" <[email-masked]>
>Subject: Re: [mobile-ip] No keying for "weak" global authentication
>
>> While I don't have a problem with this per-see I wonder how many flavours
>> will end up with. Potentially will have:
>>  - just return routability for each BU being sent - no crypto
>>  - return routability for first BU plus establish some keys so that
>>    subsequent BUs don't need the 3-way handshake required for
>>    return routability
>>  - IKE in the case when there is a PKI
>>  - Perhaps SUCV if not now but at a future date
>
>One observation I'd like to make here is that we
>have basically entered a very new area, in terms
>of existing research etc there isn't much old work.
>The whole problem of "weak" authentication wasn't 
>even known some time ago, and the the smart ways
>of handling the problem (like SUCV etc) have surfaced
>quite recently.
>
>Therefore, it would seem prudent to prepare for
>the possibility that research will come up with
>more results in the area, given some time. 
>
>Engineering-wise, this means that we should try
>to decouple the weak key management protocols
>from the rest of the system, allowing us to
>add new ones later. This decoupling might mean
>that any protocols designed for e.g. the
>return routability should be extensible to
>allow for SUCV etc at a future date, or that
>we simply have different protocols that all
>can key the same BU protection mechanism.
>
>It may also mean that we should on purpose
>try to *not* include everything we can in
>the initial spec, fearing the danger that
>we go too close to the leading edge and make
>a mistake...
>
>Jari