[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On SKIP and non-interactive key management
Ashar,
Thanks for taking seriously my comments.
In this note instead of going into a detailed response to the many issues
raised in our previous notes, I will stress several points that I believe
are mostly important regarding your design and the general issues we
face in the design of key management for IPSP.
These points already incorporate what I learned from your responses.
1) We need to decide whether the basis for IPSP key management is an
interactive protocol or non-interactive (SKIP is a good example of the
later). Even if I believe we'll finally have a mixed protocol, deciding on
the basis is significant for trade-off assessment.
2) Simplicity is indeed a fundamental issue. But simplicity is not a 0/1
parameter, and it involves trade-offs with a lot of considerations, in
particular, system and security considerations. One needs to optimize
simplicity together with these considerations. Having interactive protocols
for key sharing does NOT necessarily carry a big complexity.
We have implemented our short-lived (or session) key management protocol
from scratch in one month by one person (including debugging and testing).
This is not the whole IKMP but is basically the only piece that can be somehow
saved in non-interactive solutions.
3) Space penalty. In my opinion you underestimate this issue much below it
deserves. People have been arguing against ICVs in the IP packets
(by not having them at all or using 32 bit checksums or other insecure
solutions) and against the use of IV's just because they feel the savings in
bits are important to them. And now you come and say that the overhead of a
key (and some algorithm id's) in the IPSP header is not big deal.
One could possibly live with it if that's the only solution. But since
there are not less (and possibly, more) sound alternatives we have to
consider them.
4) Keeping symmetric shared keys unchanged for very very long period of time.
This is a weak design property (and not just "a purely implementation issue"
as you say) that needs to be avoided whenever possible.
Even if you do things as you mention like flushing keys on reboot, still the
accumulated time in which they are exposed to intruders during their long
useful life is dangerous. Remember that attackers will multiply their efforts
according to the size of the reward. Your very long lived keys are in
fact an attractive reward.
As said above, if there is no alternative or the associated advantages
justify it you can think of doing this. But is this the case here?
If you do interactive refreshments (even each 3 months) you already are in
much better shape.
5) Compromising on security without a clear system gain.
I believe that some aspects of your design compromise on security beyond
what is needed (and I am in favor of compromising on security when the
system requirements call for it). The maintenance of very long-lived keys
without changes, the exposure of all traffic to and from a party by
compromising only its private key, the exposure to some forms of
replay attacks on packet contents, are examples.
Your arguments in some of your responses that you do not see the exact
scenarios where some attacks may happen is not enough. Internet is very
heterogeneous, there are very different scenarios, different policies
and all of this evolves over time. One needs to try to be sound even in
spite of this "uncertainty". The fact, for example, that you do "not see
any reason to use weak keys for authentication" does not mean that people
will not compromise on it (you suggest triple-DES but how many will do
that?), or that weaknesses will not be found in algorithms,
or that people will not discard keys with the whole care they require, etc.
The design needs to maximize security as much as possible even in the
presence of "non-aware" users/applications and system evolution. That's
one of our roles. I will repeat it: this shouldn't come at the expense
of a complicated design or hurting system performance beyond acceptable.
But again: all these aspects have better solutions under the interactive
model.
Finally, I'll come back to the point of modular design. I believe that
a key refreshment and key derivation protocol common to different
(KDC,PK,etc) scenarios of key distribution is a great design point and a
realistic development step. And we should work on that.
But this is an issue for other note(s).
I hope to find some time to answer more specific issues you raise, but
somehow the usefulness of going into details in these long notes is dubious.
I preferred to start with the more essential points as expressed above.
Peace, peace, peace
Hugo