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

[Alex Alten <Alten@attbi.com>]

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