Me-Tarzan/You-Jane and key rollover (was Re: "Me Tarzan, You Jane" in IKEv2-05 )

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


Since Dan doesn't find streaming media to be a good enough reason for
Me-Tarzan/You-Jane, I'll provide an example of using Me-Tarzan/You-Jane
to aid in key-rollover. Recall that the "You-Jane" part provides both the ID
that the initiator was expecting to talk to, but also a reference to the
public key, and optionally, the public key as well.

{Dan, please go visit the HTTP load-balancing vendors and ask them how well
they support SSL, and you'll understand why there might in fact me hundreds
of streaming sites being served as a single IP, yet with multiple keysets
involved. And... go ask the Apache people how where a lot of the money for
the people funded to work on Apache comes from}

Postulate a key distribution system with replication and caches. DNS(sec)
CERTAINLY fits this model, as does replicated LDAP.

The key characteristic is that the caches have no reason to go look for new
information until the time to live on the existing information is
over. Further, replicated servers are not updated instantly, and may not
even know there is an update until some period of time has passed and they
decide to look. (DNS Notify are hints to look now! They can get lost)

To make conversation easiest, let's assume that the characteristic time
for the system is 1 day. I.e. if I make a change, now I can reliably be
certain it will spread everywhere in 1 day. It *MAY* spread faster than
that. 

Assume that I am the responder ("Jane").

So, there are two methods to roll one's keys in the presence of a replicated
database. This is not an emergency roll-over - we can discuss that later.

1) publish the key that I will use tomorrow, today. That guarantees
   that everyone out there will have it when I start using it.

2) always sign everything with all keys that I've published.

If I've planned everything ahead of time, then I've marked the old key
as expiring at midnight (in a conveninent timezone) today. I've also marked
the new key as not being valid until midnight today. This means that all of
the peers that I communicate with had better be able to get the new key at
precisely the right time. Otherwise, they go offline.

If I try to be smart and make the validity periods overlap, then there is
no real reason for a peer to look for a new key until the old one is no good.
(CRLs help here, but DNSSEC certainly doesn't provide them)

So, during the overlap, I will have some peers who want to connect to me
and will assume that I have switched to the new key, and some that have
not yet seen the new key, and will use the old key. I'm left with the
question: which one do I sign with?   Me-Tarzan/You-Jane lets the peer
tell me what they expected, so that I can make them happy.

You now say, well, if the peer will just look periodically for new keys
and then not use the new key until the old is expired. The problem is that
there is really no way to do an emergency roll-over if a key is compromised -
the clients will not use the new key until the old one expires.

This DEFINITELY occurs with DNSSEC borne keys. FreeS/WAN has been using 
such keys for some years now, and we have experienced *EXACTLY* this in
IKEv1. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPnaA3oqHRg3pndX9AQGkdAQArxPNmub2k1bhLUvUCGMnkJtjggrg3aoh
GS3V7dxVvvuOn9Z/mlY+BpKy2KP6T5usbvcPuJ93AyR97pXf4nTJ7oYY7NTeqN1k
C3V+AbeQkCzeOdXC4iU75HzrMvPS8gGp1gJWP8F4jy9j1sbPQ8CArCzvNKnBtXZo
qI/JzW5BQKc=
=cLTs
-----END PGP SIGNATURE-----