Re: [mobile-ip] Re: replacing IPsec's replay protection?

[Uri Blumenthal <uri@bell-labs.com>]

On Wednesday 03 April 2002 11:12, Michael Thomas wrote:
 > I honestly don't see why MIP needs to go beyond
 > saying "use IPsec, beware manual keys". 

Because nobody really WANTS to use manual keys?
And because while IKEv1 is a hog (and no real negotiation
seems necessary),  something VERY light-weight is needed?

 >That is, so long as there is a viable way of keying IPsec
 > which enables replay protection -- and there is --
 > MIP doesn't need to be any more specific *how* to
 > do that.

Don't you think there might be interoperability issues if the exact way 
of keying IPsec  is omitted?  Also, creating SA is *more* than just 
keying. 

 > If people want a lighter weight option than either IKE, JFK, KINK 
 > etc, than that is a IPsec WG problem. But MIP, IMO, doesn't need to
 > boil the ocean here. If it's an interesting problem to solve for MIP, 
 > it's an equally interesting problem to solve for a whole slew of
 > other protocols which might be protected by IPsec.
 > That is, generality good, one-off bad.

The description of the problem to solve seemed to be:

1. IPsec is preferred as protection mechanism, but
2. SA is established via IKEv1 and people don't want to pay this price.
3. So a lightweight "compact" protocol for establishing SA is needed, 
4. but it must be defined as two peers must know how to negotiate.

A  possible solution (as I see it) could be:

1. "Negotiate on paper" - i.e. define most if not all the attributes of 
SA that should satisfy usage criteriae (including the crypto suite).
2. Select a simple key agreement protocol (any Bellare-Rogaway 
derivative should do nicely) - such as *interlocked* CHAP or AKA.
3. Specify all of the above in a generic draft.

Those who can live with SA attributes specified in (1) can use this 
simple protocol and save on code and time. Those who must use full 
power of IKE will either take IKEv1, or wait till IKEv2 (hopefully 
soon).

 > In any case, my larger point here is that a
 > mandatory mechanism for MIP which requires per
 > node consumption of NVRAM on a Home Agent as a
 > MUST IMPLEMENT, where IKE, JFK, KINK, etc don't
 > place any such requirements on IPsec seems
 > onerous, and should be optional. Ideally, it
 > would be one of a set of acceptible choices.

The above doesn't make sense, because you *have* to have something in 
NVRAM regardless. The question is - exactly what. And a simplified 
approach allows you to "memorize" less than IKE or JFK would 
require. 



 > Jari Arkko writes:
 >  > Uri Blumenthal wrote:
 >  > > On Tuesday 02 April 2002 20:08, Michael Thomas wrote:
 >  > >  > If people want a "light weight" keying scheme for
 >  > >  > IPsec, it should either be pursued in IPsec WG, or
 >  > >  > through a BOF......As I've mentioned, there are some
 >  > >  > of our folks who have some interest in this, and
 >  > >  > their scheme doesn't require per node storage of
 >  > >  > anything but the key and something akin to the
 >  > >  > EngineBoots counter in SNMPv3. This would be a
 >  > >  > much better solution to this problem.
 >  > >
 >  > > Actually, this is interesting - because indeed there are
 >  > > applications and protocols that want to use IPsec for
 >  > > protection, but don't want to use IKE for key negotiation.
 >  >
 >  > This is true, but from the point of view of Mobile IPv6, we didn't
 >  > really want to enter the discussion of key management protocols.
 >  > (I'm personally sure that Son-of-IKE will solve many of the
 >  > problems IKE has, though I haven't checked lately to verify this.)
 >  >
 >  > Instead, what the Mobile IPv6 folks wanted to do was to use IPsec
 >  > as-is for certain tasks. One of these tasks was protection of BUs
 >  > between the MN and the CN. Now, our options in regards to this are
 >  > as follows:
 >  >
 >  > 1. Require IPsec + IKE. No replay problem.
 >  > 2. Require at least IPsec, but keep IKE as optional. Don't add
 >  >     any features for replay protection. Folks who don't use IKE
 >  >     will suffer from the replay vulnerability.
 >  > 3. Require at least IPsec, optional IKE but add an application
 >  >     layer feature for replay protection to prevent replays if
 >  >     you happened to not have IKE. This was the DT-recommended
 >  >     approach.
 >  > 4. Require at least IPSec and a TBD light weight key management
 >  >     scheme, perhaps optional IKE in some cases. No application
 >  >     layer features. Replay protection works perfectly for
 >  > everyone.
 >  >
 >  > Somehow I think that if we are targeting RFC in about a month or
 >  > so option #4 isn't going to give us that. However, this discussion
 >  > has caused me to rethink some of the reasons on why we recommended
 >  > option #3. Option #2 might also be quite reasonable, and would
 >  > have the added benefit that whatever the IETF keeps generating on
 >  > the key management front could easily be adopted whenever it
 >  > becomes available. KINK could be used in environments where it is
 >  > available, for instance, and Son-of-IKE when it gets ready. OTOH,
 >  > the application layer replay protection has* been in the mobile
 >  > ipv6 drafts from the stone age so I don't think that it's such a
 >  > bad idea either.
 >  >
 >  > Comments?
 >  >
 >  > Jari
 >  > *) We have been discussing a modification of the replay protection
 >  > on the list, to require NV memory to be used or not.

-- 
Regards,
Uri
-=-=-<>-=-=-
<Disclaimer>