[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SKIP insecure
I do wish that you hadn't combined all your replies into a single
message. It wasn't helpful for reading the thread. Of course, you
probably didn't like the subject headings....
The first time around, I tried to be neutral, and state succinctly and
impersonally the bare facts about the most important problems with the
proposal, leaving out the 20 or so more minor failings.
This time, you have decided to become personal, and I shall be personal
in return!
Phil, Perry, and Hugo have addressed many of your comments already. But
here's my take on this particular concern:
> From: ashar@osmosys.incog.com (Ashar Aziz)
> > While it may be that authenticated traffic does not require this
> > protection in certain instances (which are debatable), it is "a
> > desirable and appealing goal" for privacy. SKIP lack of this protection
> > for encryption is unacceptable.
>
> Lack of "desirable and appealing" is not the same as "unacceptable".
>
Please do not put words in my mouth. This was a "last call". It is
time to evaluate whether the proposal covers the desired functionality.
The quote "desirable and appealing goal" was from your own draft!
This was _my_ analysis, with _my_ name on it -- the lack makes the
proposal unacceptable to me!
> > SKIP exhibits several serious insecurities.
> >
> > The SKIP master keys are extremely long term. No matter how many
> > "reasonable safeguards", long term storage of keys carries a significant
> > security risk. This problem has long been recognized for KDCs.
>
> 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.
>
> There is no central storage of long-term keys in SKIP. Only decentralized
> storage of long-term keys. This avoids the biggest problem with
> KDCs.
>
This is WORSE than a KDC!
Because a KDC is "central" in a single place, it can be hardened.
Attacks can be managed, quantified and qualified, and made difficult.
Since the SKIP keys are all over the place, it is much harder to
quantify and qualify the attacks. Very simply, widely distributing the
secrets makes it much more likely to be breached. Humans are fallable!
> > The SKIP master keys are maintained on multiple systems. Although this
> > may be appealing for rapid "fail-over and load-balancing", and
> > "intermediate authentication", there is no IP Security requirement for
> > these features.
>
> First of all, your statement is misleading. It is incorrect to
> state that "SKIP master keys are maintained on multiple systems".
>
> Rather, they CAN be maintained on multiple systems, providing failure
> recovery properties you simply can't get with conventional session
> key-management protocols.
>
That they can is a _serious_ failing of the proposal.
> Second, please don't tell me what is and what isn't a requirement.
>
I can damn well state what is a requirement!
If you wish to contradict me, please refer to the paragraph in RFC-1825
where your requirement is derived!
> The firewall customers that I talk to (virtually every large telco,
> bank, large enterprise) ask for features like high availability far more
> than they ask about things like perfect forward secrecy.
>
I am truly amazed that you talk to "virtually every" such customer.
What an important person you are!
However, I have a certain amount of experience in the field myself, and
I dispute your findings. Oh, and I've worked on about 10 router
vendor's products, too....
> > The SKIP public-values are signed, but the generated session-keys are
> > not signed. Current literature suggests that _both_ the public values
> > and resulting session-keys be signed to prevent attacks. The signature
> > operation is not known to be associative or commutative.
>
> I am not aware of any requirement that traffic keys MUST be
> signed, since there are so many key-distribution protocols
> that involve NO signature operation.
>
Ye Gods Above and Below! You are correct. There are a lot of provably
insecure protocols! What do I care?
I can find literature references to identification and signatures going
back to Crypto '84 (over 10 years in a field barely that old) without
leaving my chair. And I don't even have much of a library here at
home....
> If you really believe that this is a significant security risk, then
> please describe an attack on the protocol, or even the beginnings
> of such an attack. I will consider your objection more
> seriously then.
>
It is not my job to prove the protocol insecure. It is your job to
prove the protocol secure!
My field of expertise is protocols, not cryptology (where I merely am
"interested"). I have analysed your protocol in respect to the current
cryptological literature available to me.
In this particular case, the literature speaks of "direct proof" of
knowledge of the shared-secret key. SKIP does not have this "direct
proof". When it does, I will consider your protocol more seriously....
> To summarize, I don't believe that you have raised any new
> issues in your comments. Only issues that have been discussed
> many times over in the last year and a half on this mailing
> list. Nor have you described any serious shortcomings or
> defects.
>
I reviewed my comments, and found the word "unacceptable" at least eight
(8) times. If the protocol being unacceptable is somehow not a serious
shortcoming, why then by all means find somewhere to publish. Just
don't bother me anymore!
> Also, you have requested no specific changes to the document.
>
I can do that easily. Start at the first paragraph. Delete the
inaccurate overview, which tells nothing about the protocol (instead
attacking other session-oriented protocols). Delete all references to
"stateless", "messageless" (or "zero-message"), "manual distribution",
"storage", "intermediate authentication", and the bloated SKIP header.
Beginning with Chapter 3 "Algorithm Discovery", design a key management
protocol. Come back again when you are done.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2