Hi to All
Real life situations have shown the need for
multiple key nego. protocols, rather than depending on D-H only
which is what IKE is using.
Regards
Ahmed
----- Original Message -----
Sent: Saturday, April 06, 2002 4:45
PM
Subject: Re: [mobile-ip] Re: replacing
IPsec's replay protection?
At 02:07 PM 4/4/2002 -0800, Jan Vilhuber wrote: >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 agree with this and
would go further and keep the number of block ciphers/modes/key lengths to
a minimum (AES-ECB-256 & 3DES-ECB). Public key usage should be a
rarely used authentication option and then only RSA (because of slowness
keys will need to be variable, but 1024 should be the supported default).
All key material should be distributed over single IP datagrams without
fragmentation (UDP should be an option, especially to help with system
debugging). All random material used for keys should come from HW
random source, either internal (Intel P4 RNG) or from external source, and
use a CRC to detect bit errors during storage retreival or
post-flight arrival. Default operation should be with a raw
authentication key inside the stack, with optional local-only KIK or
password protection when it is stored on disk (for
shutdown/reboot).
I'd recommend that the WG put out a request for a
custom hash, with a keyed option, designed to support IPv4
explicitly. It needs to be much faster than the current iterative
hashes (HMAC is massive overkill). In lieu of this, then only use
SHA-1 and possibly SHA-2.
Policy enforcement should be centralized
within an autonomous system to keep host implementations simple and to
avoid the overhead of synchronizing too many
databases.
Goodnight,
-
Alex
--
Alex Alten Alten@ATTBI.com
|