[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SKIP and interactive key management
Ashar, Hugo,
Why not use a hybrid solution, i.e., add periodic handshakes to SKIP?
On November 8, Hugo Krawczyk wrote:
>SKIP is composed of two (mostly) independent modules.
>(I'd recommend making this distinction more explicit in the draft).
>The first module deals with the sharing of a long-lived (master) key between
>two parties (i.e., two IP addresses). The second deals with the establishment
>of keys for data authentication and/or encryption in the IPSP level.
>The implicit independence between modules implies that the second one
>could use any form of master-key establishment algorithm (interactive,
>non-interactive, public-key based, KDC-based, etc).
>
>
>* The compromise of a party's private key exposes ALL the traffic TO
>and FROM this party for the whole period this key was active (e.g., two
>years). Contrast this with the "standard" DH that provides the property
>that the compromise of any key does not expose any other key (on the
>other hand, the standard DH does not provide an authenticated exchange).
>
>* SKIP forces parties to maintain VERY long-lived shared keys, namely,
>for the same periods of time for which a public key is to be kept fixed
>(1, 2 or more years!). One could argue that the maintenance of very
>long-lived secrets is a property of any public key system. However, there
>is a significant difference between a system that requires ONE secret
>to be well protected as opposed to a LOT of simultaneous secrets as is
>the case in SKIP. I am assuming here that nodes cache most of the shared
>keys with other nodes with which they have significant communication,
>otherwise the scheme turns impractical (without caching the decryption
>of each IP packet would involve the computation of a long exponentiation).
>The draft says (page 8) that protection of these cryptographic keys is
>"beyond the scope of this document", however in a case in which you need
>to maintain so many secret keys that are unchanged for two years this
>is a prime consideration.
>
To solve the problem of a very long-lived shared key, and the problem of
the whole traffic exposure, try to devise a way to use SKIP as the
SHORT-LIVED KEYS MODULE, and add a LONG-LIVED KEY MODULE that will be used
to establish a shared symmetric key between the parties. I.e., the packet
key, Kp will be encrypted by a shared master key. The master key will be
derived from the parties personal keys, and will be periodically changed.
Personal keys can be certified public keys, keys assigned by KDC, etc.
Various protocols can be used for the establishment of the master key.
The life time of the master key should be relatively long, but not too long
(e.g. a month, a week). The parties will use periodic handshakes to
establish a current master key, and a master key ID - the master key ID
will be one bit. One of the 22 zero bits of the SAID field in the SKIP
draft can be used as the master-key ID.
The master-key ID bit will be toggled when a new master key is established.
After a new master key is established, there is a fixed period of time
during which the two master keys (the new key and the previous key)
overlap. After this period of time the old master key will be discarded and
all the packets that arrive with the old master-key ID will be rejected
(i.e. discarded).
Regards,
Sara Bitan
RadGuard LTD.
Israel
972-3-6459592
Follow-Ups: