[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re:On SKIP and non-interactive key management
Ref: Your note of Tue, 8 Nov 1994 16:36:00 -0500
Dragan (and other IKMP-interested parties),
before commenting directly on your note let me stress the following point.
I said in my note that I feel that we need a proposal that is basically
interactive with non-interactive options.
I believe you are saying that we need a non-interactive approach
complemented with some interactive features.
If I interpret you correctly then we are both saying that we need a mixed
approach. Now, the discussion boils down to assesing trade-offs that
involve both system issues and security considerations.
I tried to make as clear as I could the security cost of a pure
non-interactive approach; the intention was not to *eliminate* that approach
but to create a basis for judging the trade-offs.
I believe we will need more discussion and more opinions in order to balance
the system and security needs, and still keeping a relatively simple design.
SO, LET'S WORK TOGETHER TOWARDS THIS GOAL.
My responses to the specifics of your note are "hidden" below.
Hugo
>
> >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.
> >
> Maybe prematurely, but you have not presented a single piece of evidence to
> support your statement. Now, you use this conclusion to develop a theory...
The conclusion was moved to the begining of the note just to make the
interactive vs. non-interactive point clear also to people that wouldn't
go all the way to the end of the note because of its length.
But I do think I presented a lot of points (later in the note)
to support this conclusion.
>
> >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.
>
> Well, I do not believe that all the systems I periodically access 'know' me to
> keep me in their records. If I were to access my system at work, it may be
> different, my bank to check my balance - yes. But, yesterday I called U. of
> XYZ, tomorrow I may want to call the ABC Company, ... Do I have to register
> bilaterally, in order to obtain a record?
>
Again, some provision for non-interactive key management is necessary.
But shouldn't we take advantage of the added secuirty provided by periodic
handshakes for the cases where these handshakes are possible?
A CRUCIAL QUESTION IS: how much of the traffic does not allow for such
handshakes?
> >
> >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.
>
> OK.
>
> >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).
>
> I am sorry, but I do not understand your point. Within a KMP, crypto-algorithms
> should be replaceable, not the key-management protocol we have chosen to
> implement. If you change the key-management protocol, you are talking about a
> completely different KM environment.
>
I am talking about the cryptographic algorithm. If you use public-key
encryption in your system this can be done using RSA, ElGamal, etc. or
tomorrow's great invention that will let you do encryption and decryption
with just 17 multiplications (a somewhat optimistic but not impossible
dream). If in the PROTOCOL you rely on a function that let you have a
shared secret key with other party by just having each other's public key
then I do not know how to accomplish it except for DH (here DH is a particular
cryptographic primitive). If somebody breaks DH tomorrow
(a very pesimistic but not impossible nightmare) or extends the license to
another 17 years or for whatever other reason you need to replace DH by
another thing you're stucked until somebody invents an alternative solution.
I am NOT saying that this consideration by itself should make us drop the
idea of using this solution, I am only saying that it IS a disadvantage.
> >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.
>
> Exactly - doesn't it make it better?
YES! But it has some undesirable side effects.
>
> >
> >* 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).
> >
> Here, you have a point. However, that is limited to the 'long-lived' shared
> keys, the adversary still has to calculate the 'short-lived keys'. Thus, we
> should demand stronger transformations between the two modules.
>
This is not clear to me: what are the two modules and what transformations
you refer to? In any case in SKIP's proposal if you know Kij you know
ALL the short-lived keys.
> >* 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.
> >
> Keys could be kept for a 'reasonable time' in a cache. After that, it could be
> kept of an off-line medium or simply re-computed, which ever is cheaper. Which
> is better, to keep a last year's key (that has never been used since) or to
> spend several miliseconds more recalculating the long exponentiation? I would
> prefer the latter. :-)
>
I prefer neither to keep unused keys nor to compute exponentiations.
> >
> >* 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?
>
> Good point. How often does one change algorithms? Do we change them more often
> than 'long-term' secrets (e.g. 2-3 years)? Data-keys are changed per-session or
> per-message basis, but not the 'long-term' secrets, let alone algorithm changes.
> The first time one obtains a certificate, one receives 'expiration'. In case of
> sudden changes, there is always a CRL. The worst thing that could happen is
> that a user does not receive service he/she demanded. Requesting another
> certificate from a CA should resolve this problem.
>
> >If an initial interaction for negotiation is provided why not use that
> >communication to interactively exchange keys without all of the above
> >disadvantages?
> >
> I agree with the first part of the sentence - that is just what we do, but I did
> not see any disadvantages, so far.
>
WHo is "we"? There is no initial negotiation in SKIP.
And again: if we add that initial negotiation then why not negotiate a
master key in that interaction?
If you do not see the disadvantages read my note again.
You may decide to live with the disadvantges but you cannot deny their
existence.
> >* 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.
> >
> [ ...]
> >
> >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.
>
> Yes, something should be done about it, perhaps through SAID.
>
> >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.
> >
> Agreed.
>
>
> [...]
> >
> >Hugo
>
> Now, your 'conclusion' from the begining isn't air-tight. I agree, there are
> things to improve, but the concept is sound. After all, this I-D is only
> -00.txt. :-)
>
> Regards
>
> Dragan
> --------------------------------------
> Dragan Grebovich
> Bell-Northern Research
> P.O.Box 3511 Station C
> Ottawa K1Y 4H7
> Ontario
> Canada
> Phone: + (613) 765-3524
> Fax: + (613) 763-8385
> E-mail: dragan@bnr.ca
>
>