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

Re: WG Last Call for SKIP I-D



>The SKIP defense to clogging is to have a pre-compute cache
>of master keys. In general when a SKIP node is targeted for clogging, 
>it stops computing new master keys. This does NOT result in a
>denial-of-service, since the pre-compute cache can provide
>communications with nodes with which it has pre-computed
>master keys (including brand new network connections).

Ashar,

You can deal with clogging in *any* key management protocol by simply
disabling it as long as the attack is in progress, thus disabling the
creation of new associations. Even if the system is not completely
disabled (e.g., if prior associations continue to work) I see this as
less desirable than a protocol that is designed to continue full
functioning even when it is under attack.

>The master keys can live encrypted on disk under another key, either 
>located on a smart card, or encrypted in a user password. Note
>that this does NOT represent a greater security threat than storing
>the long-term DH secret on stable storage, since the master keys are 
>all computable from knowledge of the long-term DH secret.

This is a good point and illustrates an approach that all our schemes
can use equally well to preserve state across reboots to save the
resources necessary to recompute it. At the expense, of course, of
diminished perfect forward secrecy if that is desired.

Bill has proposed long-lived AH security associations (whose keys
could be saved on disk across reboots) as one way that Photuris could
satisfy some of the low-overhead authentication-only situations that
SKIP has in the past handled better. Your comments?

>When a node is being clogged, no new certificate requests need
>to be generated. The certificate requests are only
>needed if the node actually plans to exponentiate, which
>in this case it wouldn't. No extraneous certificate queries
>would be generated during a clogging attack.

Again this is essentially a successful (partial) denial of service
brought about by the attack.

>> The storage cache can easily be overflowed, likely causing loss of

>This is purely an implementation issue. The cache can easily
>be bounded to, say, a million entries. A cache is not necessarily
>ephemeral state, it can be permanent state. This is NO different
>from a security perspective than stating that the long-term
>DH private keys are permanent state (which they are) since
>(as noted above) the master keys are computable from the
>long-term DH secret.

If the cache is not large enough to hold the entire database, then the
attacker can purposely cause it to thrash (presuming he knows the
replacement algorithm in use). Way back in my reckless undergraduate
days we used to see how long we could keep the Cornell campus VM370
system page thrashing with the minimal amount of billed CPU time. It
was amazingly easy when you put your mind to it...

>One solution for anonymity for mobile users is to have anonymous
>principal ids (either per host or per user) (represented by private keys 
>in smart cards or encrypted in some user password) that can be handed out 
>to mobile users.

I've thought about your idea, and although it might work in theory
(modulo various statistical attempts at traffic analysis) I think it
is probably impractical in practice. Perhaps if the user and system
used the SKIP encrypted channel to agree on a new randomly chosen ID
for use in the next "conversation", it might work. But this of course
adds state.

>Secure e-mail protocols, such as PGP, PEM, MOSS, etc. are widely
>used in the Internet community for encryption purposes, and these provide
>no perfect forward secrecy.

>If we accept lack of pfs for e-mail, why is it unacceptable for 
>IP? Is encrypted IP data inherently more valuable than encrypted
>e-mail data?

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.

>There is a BIG distinction between central storage of long-term
>keys (the KDC represents a single "fat target") and decentralized
>storage of long term keys. 

Agree. Still, it's best to not do even this if you don't have to.

>Decentralized storage of long-term keys is a fact of life
>for any cryptographic protocol that provides authentication,
>since one needs to securely store each principal's authentication 
>keys. 

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.

>The distinction here is the amount of decentralized 
>long-lived information. However, any technique that can protect
>a small amount of decentralized secret information can be used to 
>protect a large amount of decentralized secrets, since cryptography is
>an amplification technique (a small amount of information, i.e, a key
>can protect a large amount of information, usually data but in this 
>case other keys).

True, but it cuts both ways -- a compromise can amplify your INsecurity
in the exact opposite direction!

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.

Boy, I do seem to be mellowing in my old age. Or maybe I've just been
redirecting my combative energies elsewhere where they might do some
real good... :-)

Phil



References: