[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call for SKIP I-D
>From: Phil Karn <karn@qualcomm.com>
>
> I "accept" no PFS for email right now only because I have no viable
> alternative. I am increasingly dissatisfied with the lack of PFS
> where it could easily be supported, i.e., in interactive
> communications. I generate a new PGP key pair every year or two at
> considerable inconvenience (look at my signature list!) just to put
> SOME limit on the damage that a compromise could cause.
>
> This is one reason I've made PFS such a priority in Photuris. Still,
> I'll have to accept no PFS when operating in unidirectional
> environments until somebody figures out how to do it.
> ..
> ..
> Also true, but the consequences of a secret authentication key
> compromise in Photuris are FAR less severe than the compromise of a
> SKIP secret key. The effect of a compromise in Photuris would be
> limited to enabling active man-in-the-middle attacks which are
> inherently more difficult to mount and riskier (in terms of increased
> chances of detection) than passive monitoring attacks. If you can
> quickly detect the breach in Photuris you can essentially avoid damage
> entirely by immediately revoking the compromised key and generating a
> new one. In any event, thanks to PFS all prior session traffic is
> still protected. In SKIP all this traffic is forever compromised.
Phil,
We have been discussing this, and there is a PFS solution
possible for SKIP, that I believe will satisfy a large percentage
of users.
The solution is to let the certified DH public key be instead
a set of certified DH public keys, each of which have shorter
validity than a typical certificate, say one or two weeks. The set
of intervals over which each public key is valid would be contiguous
and non-overlapping, and the sum of these intervals would equal
the validity period of a typical certificate, say six
months or a year.
Corresponding to each short validity public key in the certificate
would be a short validity private key. A short while after each public key
expires, the corresponding private key is deleted. This limits the
effect of a node compromise to the validity period of a single
public key, (e.g. 1 or 2 weeks) thereby providing PFS/back traffic
protection for encrypted traffic sent earlier than a single
public key validity period.
This leaves the issue of making sure that communications can
switch over from one certified public key to another without manual
intervention (since 1 or 2 weeks is too frequent to expect
manual intervention for a large number of nodes).
Fortunately, this is easily solved by limiting the switch
from one public key to another to occur on an "n" counter update
boundary. Since, this contains the sender's notion of time, this allows
a receiver to unambigously know which master key to use in order
to decrypt/authenticate IP traffic.
And all of this can be done without really modifying SKIP, other
than to say that certificate management of this type is possible.
The advantage of this approach is that it still allows pre-computation
of all master keys, (no real-time exponentiations required even for encrypted
traffic with PFS) and still permit the redundant high availability
configurations (for failover purposes) possible using SKIP.
> In summary, I do agree with you when it comes to user requirements.
> Regardless of what we decide here, the market will ultimately decide
> based on what it considers most important, and it may very will choose
> a criterion we have hardly even considered. And then again there may
> turn out to be several well defined sets of needs for which one
> protocol or the other is best suited, meaning that they end up
> coexisting peacefully. Time will tell.
Yes, perhaps in time the protocols will end up coexisting
peacefully after all. I agree with you that we should let
the market decide which one suits their purposes better.
Regards,
Ashar.
Follow-Ups: