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

re:On SKIP and non-interactive key management

On November 8, Hugo Krawczyk wrote:

[...] 

 
>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...

>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?

>
>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.

>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?

>
>* 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.

>* 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.  :-)

>
>* 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.

>* 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