[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Modular approach to key management for IPSP
Hello all,
In order to have a useful and productive IETF meeting next month on the
issue of key management for IPSP, it'd help to have some preliminary discussions
on the subject in this working group. Since the last IETF meeting the only
relevant posting (that we are aware of) on key management in this list was
the recent announcement by Aziz of his draft on the "SKIP" proposal.
Although SKIP has some nice features and functionality, we believe that
IPSP requires a different approach to key management which may include
some aspects of SKIP but cannot be solely based on it.
(We defer to a future note a more thorough discussion of the benefits and
limitations of SKIP).
THE BASIC APPROACH
******************
Our basic approach to the key management problem for IPSP is that any
viable solution needs to follow a modular approach.
We advocate the separation of a key management scheme into the following
two modules: Un upper module in which a long-lived ("master") key is
exchanged between the communicating parties; and a lower module, in which
the already shared (master) key is used for the derivation, sharing and/or
refreshment of additional short-lived keys to be used for the cryptographic
transformations applied to the data, e.g., encryption and authentication.
(Short-lived keys can be thought of as "session" keys, but the existence
of a session is not necessarily required or implied.)
Moreover, we believe this WG needs to concentrate on establishing first
the lower ("short-lived") module protocol and then to go into the upper
("long-lived") module, with the former being *independent* of the specifics
of the latter.
This approach is consistent with the way this group has structured its
development strategy for IPSP, namely, first come up with an agreed-upon
network-layer encapsulation protocol (IPSP), and then complement it with a
key management protocol. This methodology supports both a gradual development
effort, as well as the independence of IPSP from the particular key management
techniques. In the same way, a gradual and bottom-up independent approach
is desirable for key management. We elaborate more on this in the rest
of this note.
WHAT ARE THE MODULES?
*********************
First let us briefly state the basic functionality that needs to be provided
by each of these modules.
LONG-LIVED KEY MODULE: Will provide a mechanism for authenticated sharing
of a secret (symmetric) key between the communicating parties. This protocol
would not assume the existence of an already shared key but is based
on some form of shared trust. This trust can be physical
(e.g., manual/over-the-phone/etc. installation techniques), based on a
trusted third party acting as a key distribution center (e,g,, the
Kerberos model), or based on the possession by the parties of authenticated
public keys of each other. Periodic (although not frequent) refreshment of
long-lived keys needs also to be provided, but this can be accomplished by
the basic exchange mechanism (i.e., long-lived key refreshment does not
require to assume the existence of an already shared secret key between
the parties).
SHORT-LIVED KEYS MODULE: This is the most "busy" module of key management.
This module is responsible for the exchange of short-lived keys, the
authentication of the parties, the derivation of "data keys" (the actual
keys used for encryption and authentication of the IP payload), the periodic
(and relatively frequent) refreshment of these keys, and the communication
of SAID's for the indexing of the keys (especially in the desirable model
where SAID's are chosen by the local implementation and need to be transmitted
to the other party).
Notice that there is no duplication of functions between the two modules.
Regardless of whether these modules are designed in a hierarchical way
as we propose or not, the above functions need to exist in any secure and
sound key management solution.
One important issue that is not addressed in the above modules is the
negotiation between the parties of the security attributes for the security
associations served by the above keys. This attributes include the specific
functions to be performed on the data (encryption only, authentication only,
both of them, etc), the particular algorithms (CBC-DES, MD5, etc.), the
frequency of key updates (based on time, usage, unilateral decision by any
party, etc.), support of timestamps in addition to nonces, interactive vs.
non-interactive updates, and so on. The exact list of possible attributes is
to be decided by this WG, and usually involves trade-off considerations between
flexibility and simplicity. Moreover, it will be the decision of this WG where
this negotiation module is to be located. It can be attached
either to the master-key module or to the short-lived key module. Or,
following our modular approach, it may reside "in between" these modules.
We defer the discussion and further treatment of this issue to a future note.
RATIONALE BEHIND THE MODULAR APPROACH
*************************************
There is a full spectrum of reasons behind the conceptual and practical
separation of the above two key management levels. A first classification of
these issues is presented next. Notice the full compliance of these
considerations with the summary on Key Management Requirements posted in
this list by Dave Solo in February of this year. Some of the elements below
are a re-statement of these requirements while other present complementary
aspects (e.g., the need for a bottom-up development methodology).
FUNCTIONALITY: Whatever the master-key exchange mechanism is, a method for
derivation of data keys from a shared key is necessary. Notice that multiple
security transformations on the data require multiple keys (e.g, encryption and
authentication). Moreover, even a single function may require more than one
key (for example, stream cipher encryption may require directional keys, i.e.,
different keys depending on the direction of the data). Also, the communication
of SAID's is essential for a model that supports unstructured and locally
generated SAID's.
SECURITY: There is a well-recognized need for *frequent* key updates.
Frequent updates are not just a good cryptographic practice (e.g., to
reduce the damage caused by a compromised key; to reduce the time/data
available for cryptanalysis; etc.), but are of particular importance
in cases where weak algorithms are used. (Weak algorithms will be part
of the Internet's repertoire of cryptographic algorithms both because
of export rules as well as for efficiency needs.)
EFFICIENCY: Efficiency is a universal consideration. It is particularly
important to have efficient key management protocols in computationally-
constrained environments (e.g., weak/loaded devices; wireless devices; etc.).
Inefficient methods would effectively lead to less key updates, with the
corresponding impact on security. While techniques like Diffie-Hellman
(complemented with authentication mechanisms) have an important role for
long-lived key exchange, much more efficient techniques (e.g. based on MD5)
can be used for the relatively frequent updates of data keys.
DEPLOYMENT: A key management protocol needs to support and interoperate
with a variety of existing key distribution technologies. Key distribution
centers (e.g., Kerberos), and even manual key installation (e.g., in
existing intra-enterprise firewalls) are popular and widely-deployed
technologies. The view that only public key can provide a full-scale solution
to key management for the Internet is well understood and agreed upon. However,
equally well-understood is that we are not going to wait until a full
certification infrastructure is in place to start providing security for IP.
Therefore, not taking advantage of the above handy technologies
would be irresponsible. Notice that we are proposing an *inclusive* approach,
in which all these technologies may co-exist. Still, the short-lived key engine
is common to (and independent from) all of them.
DEVELOPMENT METHODOLOGY: Finally, the specification of a short-lived key
management protocol supports the *gradual development* of the standard,
summarized in the following list:
1) The encapsulation protocol (IPSP);
2) short-lived/working key management (which assumes master key);
3) attribute negotiation (input to policy engine); and
4) master key management.
Agreement on a standard for the sharing of master keys may not be easy to
achieve due to the variety of existing techniques and very complex
trade-offs (e.g., public-key algorithms, certification authorities, key
distribution centers, etc.). In contrast, the management of short-lived
keys once a shared master key already exists can be based on very simple,
efficient and well-understood mechanisms. Moreover, while one can start
working with IPSP even with manually-installed shared keys, a good management
(including periodic refreshment) of the derived short-lived keys is essential
for a secure working IPSP.
Note that the above model is broad enough to accommodate a variety
of key management proposals, including SKIP (which basically contains
the above two modules: a master key exchange based on DH certificates, and a
short-lived key exchange based on encrypting the data keys in the IPSP
packet). The question behind the suitability of SKIP involves the need for
non-interactive key exchange as opposed to interactive solutions. But this
is a subject for future discussion.
This is it for now. Feedback/comments will be appreciated. A more complete
contribution (based on our presentation at the last IETF meeting) including
specific solutions for the short-lived key management will soon follow.
But the above methodology is independent of specific protocol realizations,
therefore discussions on these issues can be started right away.
Regards,
Amir-Hugo-Juan-Pau
Follow-Ups: