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

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 4 Apr 2002, Uri Blumenthal wrote:

> 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.
>

And this was the reason whereby Radia finally convinced me that having
multiple key negotiation protocols (like we have multiple routing
protocols: Different situations require different routing protocols,
so why not different keying protocols?) is not such a good thing
afterall.

For specific point-solutions (IP phones that can only talk to one
call-manager, for example) or wherever all devices are under one
administrative domain, having special keying protocols is OK. For the
internet at large, where you don't necessarily know who you'll be
talking to, not knowing what protocol you'll have to use is clearly
not a good thing.

I doubt MIPv6 falls within the 'under a single administrative domain'
rule, so I'm a bit hesitant to declare that it could use a multitude
of keying protocols, all up to the user to decide. If MIPv6 does fall
into the 'single administrative domain' use, I'll stand corrected :)

jan


>  >   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>
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847