[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
authentication state capture
Michael Thomas wrote:
> I think that SOI would be greatly facilitated by
> taking a similar middle ground. I don't care
> whether it uses Kerberos mechanisms as it's the
> technique that's important, not the bit encoding.
> Thus, I think there should be a requirement:
>
> "The protocol MUST provide a facility to capture
> expensive authentication operations into state
> blobs created by the responder and held by the
> initiator, which can be used in subsequent SOI
> protocol operations such as rekeying, SA
> maintenance, etc, and MUST be usable for a
> configurable length of time even if the responder
> loses state or reboots."
It seems reasonable to do something along these lines, but I'm concerned
about the exact requirement. In particular, the wording above creates an
asymmetry between the initiator and the responder. If the responder
crashes, restart will be quick; but if the initiator crashes with lots of
outstanding connections, it would have to go the expensive route. This
makes sense in the scenario where lots of clients each make a single
connection into a large server, but not where there is a star topology with
lots of firewalls talking to one another. It also doesn't help if
everything crashes at once (say, due to a site-wide power glitch).
Being able to restart without public key cryptography is somewhat at odds
with perfect forward secrecy. There must be information on stable storage
at the site that crashes and restarts which if stolen would allow
decryption of the session. For KINK, this is the server's secret key; KINK
provides no forward secrecy at all. Rather than have such a long term
powerful secret, I would recommend having the IKE SA keys cached in stable
storage (and erased from stable storage when the IKE SA is closed). This
would effectively mean that the IKE SA could survive crashes of one or both
endpoints. During restart, a node could attempt to restart the IKE SA. If
the other end had not timed it out (and the timeout interval could be
arbitrarily long), the IKE SA could recover without any public key
cryptography.
To support this, we would have to design a mechanism for the IKE SA to
somehow agree on sequence numbers after a crash.
Another way of getting a similar result would be for an IKE SA to go
through a rekeying exchange but *not* immediately close the old IKE SA and
start using the new IKE SA. Instead, the new IKE SA keys and state could be
stored in stable storage on both ends and use of it could begin if
something happened to the original IKE SA (like it was destroyed by a
timeout during a crash).
Do any of these ideas sound reasonable?
--Charlie Kaufman
(charlie_kaufman@iris.com)