Re: [tcpm] TCP-AO: Text for New_Key Process

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
> At Wed, 28 Jan 2009 09:58:20 -0800,
> Joe Touch wrote:
>> Eric Rescorla wrote:
>>>> I've already shown a way to achieve this without requiring the use of
>>>> the NEW key, i.e., that used two KeyIDs with the OLD key, using the
>>>> change in the KeyID to inform the endpoints. I've also described in that
>>>> email a way to achieve this using the current API, without asking TCP-AO
>>>> to generate new packets or to do anything conditional _inside_ TCP-AO;
>>>> this can (and, IMO, should) all be accomplished with an external
>>>> mechanism, with __no__ impact on the stack.
>>> I read your mechanism, but I'm not sure it works.
>>>
>>> The basic unit of operation here isn't keys but key-ids. It's true that
>>> in your example key-id 6 refers to the same key as key-id 5, but that's
>>> not something that the stack should be observing.
>> The stack doesn't observe it; the stack reports it if asked to an
>> external process.
> 
> As I've indicated before, I think this whole external process thing
> is overcomplicating matters. Key management daemons are a bug,
> not a feature, and it would be much better if things could
> be constructed so the TCP-AO module would do everything. 
> 
> 
>>> If your point is that at the time I install key-id 5 I also install a
>>> dummy key-id 6, and use that purely for signalling, I agree that that
>>> would work, but it strikes me as extremely kludgy. 
>> It allows side A to tell side B when side A has a new key installed,
>> without causing any packets to fall on the floor on side B (note that
>> retransmissions, if received, could open the congestion window
>> inappropriately).
>> The mechanism I proposed achieved with no modifications to the TCP stack.
> 
> Yes, by laying the burden on some as yet nonexistent key management
> mechanism.

We can bury the mechanism I suggest inside TCP-AO if desired, but I
think that just ends up making it even more heavyweight. Automated key
management is a mechanism that does not need to be inside TCP-AO - we
were given that direction by the ADs from the start.

>> The other mechanisms suggested all have the property of also using the
>> KeyID value as a signal. The only downside of the mechanism I proposed
>> is that is inefficient in the use of the KeyID space - however, the
>> space is large enough that this isn't an issue.
> 
> That's far from the only downside.
> 
> For one, consider what happens if key 7 is misconfigured. In Greg's
> system, everything works fine, because packets with MAC failures are
> dropped.

I cannot believe TCP-AO needs to handle misconfigured keys. This is
supposed to be a lightweight mechanism.

> In your system, the 5-6 transition is used to signal the
> availability of 7, but if that transition fails the connection just
> falls over.

It's trivial to handle misconfigured keys in a similar fashion in the
mechanism I proposed - when you get keyID6, you switch to using keyID7;
if you don't get ACKs after some timeout, you revert back. Again, this
can be done without burying the mechanism inside TCP (you can do it by
sampling the keyIDs received).

>>> There's no natural
>>> connection between the switch from 5-6 and the switch from 5-7.
>> Why should there be? IMO, it's up to the endpoints to decide how and
>> when to switch keys; key change coordination needs to be _enabled_ by
>> TCP-AO, but not provided by it. IMO, that's a KMS issue - whether
>> automated at the endpoints, or via a protocol.
> 
> Again, I don't agree. TCP-AO should work fine without some additional
> KMS, and that includes having unsynchronized key changes work correctly.

TCP-AO *supports* key management; it doesn't include it. Synchronizing
key changes is key management.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmByAMACgkQE5f5cImnZruddwCg3ZkQCiYv/I7nhosYMvXVYCwL
odoAoKUq3Fxsu0SN9crhAwC3di60GBJ1
=60My
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm