Re: [tcpm] AO-04: Text for Key Coordination

[Joe Touch <[e-mail]>]

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

Hi, all,

The key coordination mechanism described in -04 assumes that MKTs can be
used and changed in each direction independently. In specific, it
assumes that:

	sending NextKeyID=N means that the sender is
	"ready to receive" that the MKT indicated by N

		i.e., it hopefully causes the other site to
		start sending with MKT=N

The text below tries to extend that to imply that the same signal also
means a desire to force both sides to send with MKT=N, i.e., that
NextKeyID means "wants to send AND is ready to receive". I.e., it
implies that MKTs should be used symmetrically, and that coordination
should result in closure to that state.

This has several issues:

	1) the mechanism is more complex, as described below

	2) the mechanism requires resolution when both sides set
	different NextKeyID values

		i.e., if both sides change to different nextkeyID's
		that differ before closure to a new MKT, then
		it's not clear whether closure will be achieved
		or to what value.

It's not clear why symmetric key *use* should be encouraged or required.
I favor the current mechanism for its simplicity and, IMO, sufficiency.

Further, I don't see a reason why we would need to require the API to
force new keys entered into the TSAD to immediately be favored; a single
TSAD entry could apply to multiple active connections, and it's not
clear they should all change immediately as a result. I prefer to allow
the API to have the user explicitly indicate the next_key for a given
active connection (note that next_key isn't meaningful for connections
not yet active anyway).

Joe

Gregory M. Lebovitz wrote:
> Hey all,
> I sent this text to Joe for -04, but it didn't quite make it. This text
> may or may not need to be in the spec. Personally, I'd like to see it in
> an example, or in an appendix, because I think it really makes clear how
> the coordination occurs in tricky case. I do think the rules need to be
> included in the main body text.  Pls comment:
> 
>     > ============
>     > For three keys K1, K# and Kx
>     > When only K1 is entered into TCP, set
>     >   KeyID = K1
>     >   NextKeyID = KeyID
>     >
>     >  send K1,K1  (per KeyID, NextKeyID convention)
>     >
>     > When K# is entered, set
>     >   KeyID = K1
>     >   NextKeyID = K#
>     >  send K1,K# and continue sending K1,K# until K*,K# is received (where
>     > "*" is wildcard ANY)
>     >
>     > Once receive K*,K#
>     >    K1 - start 2MSL timer
>     >   set KeyID = K#
>     > AND
>     >   SEND K#, K#
>     >  -thus, will no longer send with K1, even if receive a segment out of
>     > order with K1,K1 because already know that other side has and can use
>     > K#, and K# has higher preference over K1.
>     >
>     > When Kx is entered
>     >   K1 - MSLtimer !=0
>     >   KeyID = K#
>     >   NextKeyID = Kx
>     > AND
>     >   SEND K#, Kx  until K*,Kx is received.
>     >
>     > Once receive K*,Kx
>     >    K1 - MSLtimer !=0
>     >  set
>     >    K# - start 2MSLtimer
>     >    KeyID = Kx
>     > AND
>     >    SEND Kx, Kx
>     >
>     > In the below case, we assume K1 was current, then K# and Kx
>     respectively
>     > where entered in quick succession.
>     >
>     >   KeyID = K1
>     >   NextKeyID = K#
>     >
>     > if no segments are received from Alice with K# in NextKeyID, then K#
>     > never gets set to KeyID, and as such no segement is ever sent MAC'd
>     > using K#.
>     >
>     > Then Kx is entered into Bob's TCP. Now:
>     >
>     >   KeyID = K1
>     >   K# - start 2MSL timer
>     >   NextKeyID = Kx
>     >
>     > because
>     >   (a) we never made the shift to sending protected with K#, and
>     >   (b) K1 is the only known good key for both me and Alice, so far, and
>     >   (c) there can only be one NextKeyID, and Kx was the last entered, so
>     > it gets NextKeyID
>     >
>     > In JT's out of order arrival example...
>     >
>     > The following flag settings would exist on Bob:
>     >   KeyID = K1
>     >   K# - 2MSLtimer !=0
>     >   NextKeyID = Kx
>     >
>     > For snd = what Alice sends, rcv = what Bob receives, rply = what Bob
>     > sends next (and we drop the "Ks" for ease of notation)
>     >
>     > snd  rcv  rply
>     > -----  ----   -------
>     > 1,1  1,1   1,x
>     > 1,#  1,x   x,x  Bob executes K1 start 2MSLtimer, AND KeyID = Kx,
>     >                      AND NextKeyID=KeyID
>     > 1,x  1,#   x,x
>     > (at this point Alice would start sending x,x)
>     > (even if she didn't for some reason, like she hadn't yet received back
>     > an x,x from Bob due to drops or latency, it would look like:
>     > 1,x  1,x   x,x
>     > 1,x  1,x   x,x
>     > 1,x  1,x   x,x
>     > ...
>     > (until Alice finally received an x,x from Bob, and thus started
>     sending x,x)
>     > x,x  x,x   x,x
>     > x,x  x,x   x,x
> 
> 
>     > The rules describing all this are:
>     >
>     > For local values of
>     >    KeyID
>     >    NextKeyID
> 
>     > SENDING:
>     > IF NextKeyID = KeyID, send KeyID(KeyID), NextKeyID(KeyID)
>     >   ELSE send KeyID(KeyID), NextKeyID(NextKeyID)
> 
>     > KEY MOVEMENT:
>     >  when you receive a NextKeyID = Ky from peer:
> 
>     >   IF for local Ky 2MSLtime != 0, then do nothing
>     >   IF local KeyID = Ky, do nothing
>     >   IF local NextKeyID = Ky, and NextKeyID != KeyID
>     >      THEN, given a current KeyID = Kx, start Kx 2MSLtimer
>     >    AND set local KeyID = Ky
>     >    AND set local NextKeyID = KeyID
> 
>     > ENTERING KEYS INTO TCP:
>     >   When a new key Ky is entered into TCP, for an existing Kx:
> 
>     >   IF NextKeyID = KeyID, THEN set NextKeyID = Ky,
>                  now KextKeyID = Ky and KeyID = Kx
>     >   IF local Kx = NextKeyID != KeyID, THEN set Kx 2MSLtimer,
>     >        AND set NextKeyID = Ky
>     >   IF Ky 2MSLtimer != 0, THEN set Ky 2MSLtimer = 0, AND NextKeyID = Ky
>     >      (This one is for repeated keyID value usage, or correcting a
>     config
>     > mixup.)
>     >     or we might want to say:
>     >    IF Ky 2MSLtimer !=0, THEN throw error "Ky already in aging state,
>     > cannot install"
>     >
> 
> Thoughts?
> Gregory.
> 
> +++++++++++++++++++++++
> IETF-related email from
> Gregory M. Lebovitz
> Juniper Networks
> g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknH2rkACgkQE5f5cImnZrv4cgCdGGl76ducLvmgwR8lyXKp0RZS
eaAAoLiPUq9nn/h3axscGxn6NaiJ/xOU
=pFhi
-----END PGP SIGNATURE-----