[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call for SKIP I-D
> From bsimpson@morningstar.com Tue Nov 14 23:22 PST 1995
>
> Here is a digest of my last call responses:
>
Bill,
Thanks for your comments.
Here are my reponses to the issues that you raise.
> SKIP fails to provide adequate anti-clogging, at the protocol,
> computational and resource levels.
I don't agree with any of these assertions.
> SKIP also lacks graceful recovery mechanisms.
>
> For example, a WWW server which accepts traffic from arbitrary clients
> is easily clogged. As this is a principle application, such a failing
> is unacceptable.
>
> Whenever a packet arrives with a master-key for which it does not have
> the certificate precalculated, SKIP locates a certificate (requiring a
> certificate protocol exchange) and calculates a Modular Exponentiation.
>
> When SKIP scales to hundreds (or millions) of nodes, it will be a simple
> matter to completely swamp the target by sending a perfectly valid
> SKIP header with each of the world-wide master identifying numbers,
> triggering a search for the certificate, validation of the certificate
> signature, and calculation of the shared-secret.
This is not true. The clogging defense in SKIP, described in
section 1.8.3 of the 04 draft, adequately protects against this.
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).
Millions of nodes simply means a million or so master keys.
If we assume 16 bytes per key, this comes to 16 Mbytes of
storage. Even on very low end machines, 16M is a small
amount of storage, since 0.5G to 1 G disk is pretty normal
storage amounts these days. Assuming 16 MB spare on a disk on
a node capable of handling a million nodes is not excessive.
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.
All this will result is in denying *unusual* access patterns
service. A million or so usual patterns can still get service.
> This is unacceptably protocol inefficient, as it generates a large
> number of extraneous certificate query exchanges.
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.
> This is unacceptably computationally expensive, as the signature and
> shared-secret (Kijn) are calculated.
>
> The storage cache can easily be overflowed, likely causing loss of
> storage for other applications. In the even of loss of cache, this
> requires recalculation of other valid traffic master-keys -- yet another
> additional computational expense -- possibly resulting in lost traffic.
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.
> This problem is due to the tremendous amount of long-term stored state
> required by SKIP, and the lack of LifeTime.
>
> Recovery (as stated in the draft) requires manual intervention by the
> system administrator to add each valid user to a "pre-compute cache".
> This is unacceptable.
You have misunderstood the intent of the draft. The manual
intervention is there to allow *unusual* access patterns
*during* a clogging attack. Unusual access patterns are the only
class that may be denied service.
If one is willing to disallow unusual access patterns service (i.e.
not one that cannot be fit into a cache of a million or so
entries) then NO manual intervention is required.
I suspect that most people would be perfectly happy if a million or
so nodes could get service during a clogging attack (including make
brand new network connections).
All of this was discussed in great depth almost a year ago,
on the ipsec mailing list.
> SKIP fails to provide adequate anonymity.
>
> In order to scale, SKIP certificates will need to be widely available,
> making it easy to compile a world-wide database. The name space must be
> searchable for deployment to scale.
>
> Use of a hash, public-value, or other index to identify the master key
> is easily searched among all known master certificates. The type of
> certificate used is transparently identified in the SKIP header.
>
> Protection of anonymity by private manual configuration and/or assuming
> very large and unsearchable name spaces (page 15) is unacceptable.
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.
These anonymous smart cards can be rotated among users, so that it isn't
possible to know who is using a particular anonymous principal
ID at any point in time.
This can be implemented with SKIP, without requiring any change
to the protocol.
> SKIP admittedly does not provide "perfect forward secrecy" (back traffic
> protection).
>
> 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".
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?
> SKIP headers range from 28 to 60 bytes, not including the IP Security
> headers (only 4 to 8 bytes).
You are comparing apples and oranges.
For SKIP, you are counting algorithm specific information (the encrypted
key is algorithm specific) but for ESP/AH you are only counting algorithm
independent information. If you count algorithm specific information, the
overheads are quite comparable. For example, for AH with keyed MD5,
the per packet overhead due to AH is 24 bytes.
The SKIP header can be as small as 20-28 bytes, (which BTW is probably
going to be the common case in initial SKIP deployment). This is either
slightly *less* or slightly more header overhead as compared to AH with
Keyed MD5 (24 bytes).
Not counting algorithm specific information for one case, but counting
it for the other case is misleading.
> SKIP trades "zero-message" initialization with manual configuration --
> or a few "optional" certificate discovery messages otherwise -- for
> continuous bandwidth degradation on every datagram.
>
> The Internet Protocol Security Working Group spent considerable time in
> designing the ESP and AH headers to be as small as possible.
>
> Considering that the average TCP payload is 13 bytes, and the average IP
> datagram is 124 or so bytes, bloating every datagram by an extra 50% to
> 200% is unacceptable
First of all, if you assume avg SKIP header as 20-30 bytes,
this comes to 16-24% of a 124 byte packet (and not 50-200%).
Of course, 124 bytes is a small sized packet, and throughput critical
applications (ftp etc.) will use larger packet sizes, like 512 to 1024
bytes. This brings the header overhead down to 4-6% for 512 bytes and
2-3% for 1k bytes.
Assuming worst case SKIP header overheads with small sized
IP packets is quite misleading.
Second, why don't we leave this to the community to try and
decide if this is acceptable or unacceptable.
We are making our source software freely available so that
people can try this in the environments that matter to them.
If people don't like any part of it, nobody is forcing them
to use SKIP or anything else for that matter.
[I have been privately informed that the April '95
Merit/NFSNET backbone statistics shown an average IP
datagram size of 266 bytes for TCP services. The current
boom in WWW traffic is pushing IP packet sizes up, not
down.]
> 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.
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.
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).
> 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.
Second, please don't tell me what is and what isn't a requirement.
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.
If we are asking the user community to trade off perfect secrecy
for availabilty, then let's let the user community decide this.
> Every node that has the duplicate master keys is
> another potential security risk. This makes the security risk even
> worse than KDCs.
Like I said, SKIP doesn't REQUIRE the master keys to be
duplicated on multiple nodes, it PERMITS you to do so,
providing highly desirable features that you simply can't
get with other approaches.
> 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.
As one example, look at ANSI X9.42, which uses certified DH keys to
come up with per session keys which are not signed. There is also
a protocol due to El Gamal, which is some kind of ISO draft
standard, that generates session keys using certified DH
keys, which are not signed. I am not aware of attacks or
vulnerabilities in either one of these schemes.
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.
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.
Also, you have requested no specific changes to the document.
Therefore, at this point in time, I don't have any editorial
action to take, based on your comments. Of course, if there
is clarifying text that you would like to suggest that may
help remove some of the misunderstandings that prompted your
messages, I will gladly add such text, provided you supply
me this text.
Kind regards,
Ashar.
Follow-Ups: