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

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

On Wednesday 03 April 2002 12:51, Michael Thomas wrote:
 >>   I don't think that "interoperability" is quite
 >   the right word here. A mobile node and home agent
 >   which run IPsec/IKE could be interoperable.
 >   However, in practice unless I am part of that
 >   domain, know the right authentication
 >   mechanisms, etc, we might not be able to
 >   mutually authenticate. 

Hmm, I see your point. But:

 >  This is a deployment
 >   issue, however, not an interoperability issue.

Not quite, because if one implementation chose KINK
and another - IKE, they won't be able to talk regardless.

 >   Use of IKE, SOI, KINK, manualkey, manualkey+
 >   are all deployment isses, IMO.

I disagree for the reason stated above. Where to get certs
may be a deployment issue. Whether certs are supported,
clearly is not just deployment...

 >   .....I think it's quite reasonable for MIP to say
 >   that something better than straight manual keys
 >   is needed, but specifying how it's accomplished
 >   shouldn't be a requirement any more than MIP
 >   shouldn't be saying that you must implement IKE
 >   with certs or IKE with pre-shared keys, or IKE
 >   with AAA hacks, or whatever.

Saying "must support IKE" implies a whole bunch, including
support for certs and pre-shared keys. If you happened to
implement IKE (as currently specified) without cert support,
you just produced a non-conformant code.


 > > 1. "Negotiate on paper" - i.e. define most if not all the
 > > attributes of=20 SA that should satisfy usage criteriae (including
 > > the crypto suite). 2. Select a simple key agreement protocol (any
 > > Bellare-Rogaway=20 derivative should do nicely) - such as
 > > *interlocked* CHAP or AKA. 3. Specify all of the above in a generic
 > > draft.
 >
 >   IMO, at the point you have to put a shared key
 >   into both boxes, you might as well put the rest
 >   of the information in there too. At the point
 >   you want to start negotiating stuff, you've
 >   already gone beyond "lightweight" IMHO :-)

1. You have to put something, period - be it a pre-shared key for IKE,  
or certs for IKE, or pre-shared key for something else. No way around 
it. Otherwise you won't be able to authenticate.

2. Negotiaton can be limited to auth and derivation of the key - sounds 
very light-weight to me.


 > > 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.
 >
 >   You don't need *per node* permanent memory for
 >   IKE/KINK/SOI. That's the difference.

And where would you store the secrets that IKE/KINK/SOI require, if not 
in per-node permanent memory?
-- 
Regards,
Uri
-=-=-<>-=-=-
<Disclaimer>