[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On SKIP and non-interactive key management
>From ipsec-request@ans.net Tue Nov 8 13:58:42 1994
>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.
Hugo,
Thanks for the detailed comments.
Let me provide some general perspective of why we decided on a
scheme like SKIP, before I comment on the specific issues you
raise.
It was not just that some environments can not afford periodic
handshakes, as you suggest, although having no handshakes is
clearly desirable in many circumstances. Examples of this include
"lightning bolt" (secure) system management, infrequent or sparse
traffic applications etc.
The primary motivation of SKIP is simplicity along with a high
level of security.
What we wanted to avoid was the complexity of creating and managing
pseudo-sessions underneath IP. An example of what this entails can be
found in the 115 page SAMP document that Paul Lambert distributed at
the last IETF meeting. And this only talks about session management,
not key-management. We wanted something that we could easily implement
without a legion of programmers.
And to a large extent, sundry bugs in the current document
notwithstanding, I believe we achieved our basic goals with SKIP.
I'll point out that we had a working prototype of SKIP in an
IPSP like protocol, just 4 weeks after we started building it,
with a total of 2 people. The primary reason for this is the
simplicity of the scheme.
I brought this along with me at the July IETF meeting in Toronto, which
occurred 7 weeks after we started writing software. And it has
worked fine ever since, requiring little or no maintenance of the
basic system other than performance tuning of various cryptosystem
implementations on our part, and bringing it in compliance with the
IPSP "strawman" that was discussed at the last meeting.
We already had a session-oriented key-management protocol that
Whit Diffie and I had designed (on paper) earlier (which is quite secure)
for a connection oriented protocol and we could have simply plugged
that in for IP, but we didn't for the reasons I mentioned above.
>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.
This is not true. I mention the use of manual key-distribution in
section 2.5. I dont mention KDC, because KDC can also be used for session
key establishment, and therefore I didn't think it was necessary
to mention just for the master key establishment.
>* 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.
This isn't true either.
SKIP is generalizable to other DH like algorithms. By other, I mean
algorithms that involve different number theoretic constructions, and
also different number theoretic approaches to cryptanalysis.
An example of this is DH like key-agreement using elliptic curves over
finite fields. The nature of the Discrete Log (DL) problem is different
for elliptic curves over finite fields than the basic DH DL problem.
Also, the objection you raise against SKIP applies to any protocol that
uses DH. I'll note that DH is in various stages of standardization
in, e.g 802.10 and X9 committees.
To the extent that there is a drop replacement for DH (use your secret
and combine that with another to public to compute a shared secret), it
will be useable by SKIP.
>* 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).
Some comments on this issue:
Forward secrecy (which is what you are referring to) is desirable
in many circumstances. Clear examples of this include protocols
for secure telephones, where what is discussed doesn't reside
in easily accessible storage devices. It is also good for computer
data protocols which involve transient data.
However, many commonly used network protocols transfer data that
is long lived on storage devices. Any compromise of long-term
keys does compromise authentication, and therefore the privacy
of the data that lives on long-term storage. Examples of this
include file transfer protocols, e-mail etc, which are common
uses of the Internet.
Therefore, from a system design perspective, since authentication
failures lead to privacy failures, protection of long term
keys is important whether or not the protocol sports some form
of forward secrecy.
Forward secrecy also does not make sense in cases where weak
cryptosystems are used, because it is easier to brute force
attack the traffic than it is to actively recover keys from
tamper-resist devices. (Many circumstances oblige us to use
weak cryptosystems.)
This is not an argument against forward-secrecy, just an attempt
to highlight the various issues. Protocol design involves making
tradeoffs. I note that in your original proposal you dont propose
perfect forward secrecy (a la DH), but rather good forward secrecy,
where compromise of both parties' private keys *does* compromise
past encrypted data.
This one example of a tradeoff that people (like yourselves)
make in favor of other issues, like performance.
At the last IETF I did mention how one could combine traditional
DH with SKIP to achieve authenticated perfect forward secrecy (and with
better performance than other authenticated perfect forward secrecy
solutions), but have resisted putting this in the draft in order to
avoid the complexity issue I described earlier.
>* 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).
This is purely an implementation issue. One doesn't have to forever
cache a computed shared key. For example, in our current implementation
the cache of shared secrets is flushed on reboot. The secrets
are easily recovered using a single exponentiation for each one,
and are then cached for the duration of that power-up period.
The tradeoff isn't: do it forever, or else do DH for each packet.
>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 reason I state that is because, in standards parlance, this
is a "local issue". It is not a protocol issue. But I will describe
this and other implementation issues in a "SKIP: Design and Implementation"
paper that I am currently writing, and hope to finish before the next
IETF.
>* 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?
How does an end node decide what should be the outcome of a
particular negotiation? This cannot be hard coded in an
implementation for all possible applications above IP.
The answer is: system management. This is the way we control
the choice of algorithms etc. I will mention these issues
as well in the paper I am writing.
>If an initial interaction for negotiation is provided why not use that
>communication to interactively exchange keys without all of the above
>disadvantages?
Because what algorithms to use with a given node doesn't change
as often as keys need to change.
>* 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.
Can you provide reasons for why one might need signature capability at the
IP layer? SKIP accomplishes, privacy, authenticty etc. for both unicast
and multicast IP without using signatures.
If there is a demonstrable need, I would have no problems in accepting
DSS or RSA or whatever signature algorithm in addition to DH public keys.
>* 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).
>
I am afraid I cant agree here. What you suggest is infinitely worse
than the comparison I was making between RSA and DH. I was comparing
the case of cached shared keys (derived using DH) used to decrypt
the inline packet keys as they changed. I was comparing that with inline
RSA encrypted keys, for which you would do an RSA decryption when the key
*changed*, (not on every packet). Of course SKIP does better
computationally here.
What you are suggesting, RSA encrypting the key and part of the data
packet requires an RSA decryption on *every* received packet (since
the data will change in every packet, even if the key doesn't).
This is infinitely worse than SKIP, and has no hope of ever being
better, no matter what caching strategy is employed.
> - 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}?
MD5 is a one-way function. So is modular exponentiation. Computing
the MD5 of the output of DH is much like computing the MD5 of
an MD5 output, if one doesn't need the whole MD5 output. It isn't
necessary. (I'll note that a draft X9.42 document uses essentially
the SKIP technnique for deriving a key from a DH exchange).
I'll stop here, as this note is already too long, and continue
with the rest of the issues you raise in a follow-up note. This
will give you (and others) to comment on my responses, and we
will hopefully be able to do this work in parallel.
Please keep the comments coming!
Ashar.