[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On SKIP and non-interactive key management
This is a long note most of which is dedicated to comment on the SKIP
proposal for IPSP key management (draft-ietf-ipsec-aziz-skip-00.txt).
However, the most important issue here is not the specific comments on
SKIP but the need to decide on the right approach and requirements for
key management for IPSP. SKIP brings up a particular dimension of this
problem, namely, whether the basic key management protocols need to be
"interactive" or "non-interactive". By interactive I mean protocols
based on periodic handshakes between the communicating parties in which
keys, SAID's and other security parameters are established (the frequency
of these handshakes can be hours, days, weeks, etc. depending on the
security requirements of the specific parties). In contrast, non-interactive
solutions do not require handshaking and are based on unilateral
derivation/transmission of keys.
It may seem at a first glance that the second approach is better since
it is more general. It applies even for those cases in which handshaking is
not possible or convenient. However, the choice becomes harder when one
realizes the security cost of non-interactive (only) solutions.
Actually, let me already "SKIP" to the conclusions of this note:
Non-interactive solutions are acceptable ONLY in those scenarios where
the nature of the communications does not allow for periodic handshakes;
whenever handshakes are possible then an interactive approach is the
right choice.
If this conclusion is accepted then the next step is to decide on the kind
of dominant traffic in the Internet. If, as I feel, most of the traffic is
between parties that can afford periodic handshakes then the interactive
approach is to be chosen. Otherwise, non-interactive solutions, and SKIP
is a good basis for them, are the right choice.
Of course, there exist mixed approaches. I particularly see the final key
management solution as being based on interactive methods with some options
for non-interactive secured communications. Indeed, such options can be
added to an otherwise interactive solution at a moderate cost in the
complexity of the whole system (e.g., by taking advantage of the STPI field
in the IPSP packet).
Now, let me turn to the comments on SKIP. Most of these comments are
not particular for SKIP but hold for the general non-interactive approach.
SKIP is a good illustration of these methods and issues. I assume the
reader is familiar with the draft.
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 comments below are separated according to the module they apply to.
Master key sharing
******************
A first issue with the particular SKIP proposal is that it does not provide
for master-key sharing using alternative techniques (manual installation,
KDC, etc). However, this is in a sense not essential since, due to the
independence of modules pointed out above, the master key sharing module
could be replaced or co-exist with other mechanisms.
SKIP uses Diffie-Hellman in a somewhat non-standard and very elegant
way. It allows two parties to establish a shared secret key without
ever (directly) communicating between them, except for the sharing of
certified public-keys of each other.
This functionality and elegancy come at the expense of several important
disadvantages and constraints. NONE of which applies to (good) interactive
solutions. Some of these issues are described below.
* SKIP relies on the ONLY known (to me) technique that achieves the above
"implicit" sharing of a master-key. This violates the very desirable property
that a solution should be implementable using different algorithms (a
property especially desirable in the case of cryptographic algorithms).
Notice that PK systems that allow for encryption (e.g., RSA) can be used
to communicate a key from one party to the other, however, the uniqueness
of SKIP is that it provides a shared key even *before* any message is
transmitted between the parties.
* 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.
* The purely non-interactive solution does not accommodate any form of
security attributes negotiation. How do I know what algorithms and other
parameters I am supposed to use with a given party. Is this published in the
certificates? Is it a fixed policy for the whole Internet?
If an initial interaction for negotiation is provided why not use that
communication to interactively exchange keys without all of the above
disadvantages?
* SKIP requires public key certificates which do not provide for signature
capability. In principle, this could be alleviated by extending these
certificates to provide signature capability, e.g. via the DSS.
* Some additional observations:
- Referring to the alternative of using RSA to encrypt the transient key Kp,
the draft says (line -3 page 2) that "the protocol and computational overhead
of such scheme [i.e., RSA-based] is very high". I agree that the space
overhead is significant and that SKIP does much better (that's THE advantage
of SKIP). I agree also that the computational overhead is very high,
however SKIP does not do better. (In fact, SKIP does worst since RSA
encryption+decryption is a few times faster than a DH exponentiation -
depending on the public exponent and implementation). Moreover, notice
that the very significant space advantage of SKIP relative to RSA is
for the cases where the IP node caches the master keys it shares with
others. Without this caching one could use RSA and utilize the "wasted"
bits beyond Kp to encrypt under the same RSA encryption (part of) the
data bits. In this way the space overhead is the same as in SKIP (except
if the whole packet is less than the modulus size minus Kp size).
- Is the derivation of Kij as the high-order bits of a^{ij} optimal?
Or, is it better to derive it, say, by applying MD5 to a^{ij}?
What about derivation of multiple keys (e.g., for key encryption and key
authentication). Should such a scheme support more than one way to derive
Kij? This would require the specification of this algorithm in the IPSP
header (adding to the space demands).
Data key sharing
****************
* Attaching keys to each packet.
The most significant protocol penalty of SKIP is probably the need to transmit
the data key(s) Kp in each packet. Even if you have most of your traffic
directed to a single node (or group of nodes) with which you use an unchanged
Kp for many packets still you transmit this key with each packet. This
results in 100 or more bits for communicating a redundant information
(much less bits can do that job, e.g. via a SAID). This significant
space overhead is clearly undesirable; moreover, it "encourages" the
implementation of shortcuts to alleviate this situation. An example is
provided by the draft itself that after recognizing the need for both
data encryption and authentication keys proposes to have one key as the
prefix of the other (page 7). That's a bad cryptographic practice that
compromises security and is solely motivated by the above need to alleviate
the space overhead.
* The transmission of algorithm identifiers and possibly other security
attributes with each packet adds to the overhead even if these values are
most of the time fixed for a pair of nodes.
* The IPSP packet becomes key management dependent (and viceversa)
* The attractive notion of unstructured SAIDs that are decided by the local
implementation and transmitted to the other party is lost here. Only
structured, standardized SAIDs make sense.
* Replay of Kp. There is nothing in the current proposal to prevent the
replay of the data key Kp. To be more specific let Kp be a key used by
node i to authenticate some information transmitted to node j. Assume
that an adversary A happens to know this Kp. A can then resend the key
Kp encrypted under Kij in a packet to j and authenticate the new information
(as coming from i) by using Kp. (Notice that A knows how the encryption
of Kp under Kij looks just by taking it from the original packet from
i to j). One could wonder how does A know Kp. We usually hope that this
does not happen but our role as security designers is to have less hope
and more safeguards. Indeed, Kp (which is a transient key and then possibly
less protected or may be even a cryptanalyzable weak key) can be broken
with time (the above attack does not require the replay to happen shortly
after the legitimate use of Kp) or could be legitimately known by A.
To illustrate the later point, consider a scenario where i sends to both
j and A the same information authenticated with Kp and then transmits
Kp to each of them encrypted under the respective master keys Kij and
KiA. In this case, A legitimately learns Kp (and, with some added curiosity,
also the value of Kij(Kp)).
* The above attack can be alleviated by the use of timestamps (or in some
cases key sequence numbers). Even in this case, this provides weaker
security than achievable by interactive key exchange.
Some issues to be considered are:
- addition of safeguards against replay (of Kp)
- if timestamps are used (can we trust them? i.e., assume reasonably
synchronized clocks even in the presence of a malicious adversary?)
they could be used as arguments to a pseudorandom function in order to
derive the key(s) Kp instead of explicitly encrypting Kp. This saves space.
- combine non-interactive options into a basically interactive key
management scheme (we plan to do that for our proposal).
Can use the STPI field for the case in which per-packet keys are
transmitted. Can use both structured and unstructured SAIDs (one bit is
enough to differentiate between them).
Note: I have not commented about the specifics of the SKIP extension
for multicast since I personally do not feel I understand all the issues
involved in that problem. However, from the SKIP proposal itself it
looks that extensions for multicast can be added to basically interactive
key management solutions as well.
Hugo