[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

working keys



The purpose of this note is to open a discussion on the need
for freshness in the keys used by IPSP to compute the different
cryptographic functions (encryption, authentication, etc),
and ways to achieve this freshness.
Let me stress from the beginning that (IMHO) this is not a high
level issue but an essential piece in the basic key management
required by IPSP.

Although, there have been discussions in the list about the purpose,
structure and information in the SAID,  I saw no discussion on the
ways in which two parties decide on their common keys for application
to the security transformations, and how this information is carried
in the SAID.

I am NOT referring here to the way two parties exchange A FIRST
SHARED KEY (that is a more complex/controversial issue
about particular public-key techniques, the support of key
distribution centers, etc). I mean, how the parties derive
session keys (or working keys) from an already "master shared key".
(Since sharing a key using PK or KDC techniques may be expensive,
one would want to expose this key to a minimum, e.g. use it just to
derive other "working keys").

The only implicit solution on this issue that was considered is the
one proposed by Ashar in SKIP. Namely, the sender encrypts
the (working) encryption key (what about authentication key?) under the
"master" shared key (which in case of SKIP
is derived from the public/private keys of the parties)
and attaches these encrypted key(s) to the (encrypted) IP packet.

This "one-way solution" can be useful and desirable in some cases
but it lacks the level of security desirable and affordable in many,
possibly most, cases. A basic problem with this one-way solution
is the fact that an adversary that gets
to know one encryption/authentication key from the past
can reuse it to send encrypted/authenticated information of its choice
without the receiver being able to detect the cheating.
(A sound cryptographic design needs to provide protection
against re-use of past compromised keys; compromise
can come from temporary breaks into an interent node, cryptanalysis, etc)

These problems can be solved via mechanisms for key refreshment
in which the parties re-share keys such that the compromise of
old keys doesn't help reusing them or breaking the new ones.
We have presented such a key refreshment mechanism in our proposal
(let's call it STEP: Secure Tunnel Establishment Protocol)
during the IETF.

Indeed, whoever was there (or saw our posting to the list
on 6/1/94) could notice the simplicity of that protocol
(it appears in our proposal as a sub-protocol for
session-key establishment).
Although this solution requires interaction between the parties,
it is very efficient (in particular, uses no public-key operations)
and needs to be done only periodically (the frequency would be
a function of the security the specific parties require).
The same interaction can also carry  negotiation of
other parameters like crypto algorithms, length of keys,
expiration of keys, etc.

We intend to post to the list a more complete proposal in this
sense, but we are interested in comments people may already have on
this kind of approach.
In particular, how SAIDs should be used to carry information
about the key in use.

Hugo


Follow-Ups: