[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On shared keys (was RE: SOI: identity protection and DOS)
Thanks for the discussion and see my comments in line.
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Friday, November 30, 2001 11:52 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)
[david]
Cliff,
Let's agree that the pre-shared symmetric key will only *intended* used by
two devices. Let's look at a 5 devices network and a central keys deposit
server. For key management purpose, both the pre-shared RSA public keys and
the symmetic keys will be in a server. (Don't see any scalable model other
than this)
For a fully meshed communication model among these 5 devices:
1) the symmetric keys case:
The server have to store 10 = (5*4)/2 s. keys. and keep track of which link
associate to which key. Before device_1 communicates with device_2, these
transactions have to happen: the sk_12 will be sent from server to device_1
and device_2 through out-of-band secured channel. (well, this dynamic model
is scalable otherwise if the 10 keys pre-loaed on each of the 5 devices; it
will be difficult when a device join-in...) After the full mesh is reached,
each device will have 4 Skeys.
2) the RSA keys case:
The server have to strore 5 public keys and don't care about link info., but
have to associate device to its public key. Before device_1 communicates
with device_2, these transactions have to happen: the pk_1 is sent to
device_2 from server and the pk_2 is sent to device_1 trough out-of-band
secured channel. After the full mesh is reached, each device will have 4
public keys and its own private keys.
Observation:
1. The symmetric key management model shows that for a single skey, there
are 3 parties know it. The 2 devices and the server. Clearly, get the skeys
in the server is most effective to break entire mesh. In contrast to the
symmetric key, get the public-keys in the RA does not break any secure link.
(therefore, you can let 3rd party manage this server "RA", as long as it
guarantees id/public-key bindings)
[cliff] agree. In this case, a server break-in is a very serious security
breach and it can jeopardize the whole operation. When such an event
happens, even though the attacker can't take advantage of the public key, he
can do enough damage to other things such as billing, device configuration,
etc.
In contrast with the server break-in case, a device compromise is much more
likely. Let's take a look at this case. In a full mesh setup, PSK or
pre-shared RSA suffers the same degree, say 4 partners are compromised.
However, in a hub-spoke setting where only 4 tunnels exists, if a spoke is
compromised, only the link to the hub is compromised when PSK is used. If
pre-shared RSA is used, then potentially communication to both hub and the
rest 3 spoke can be compromised. So in that case, pre-shared RSA is worse
than a pre-shared key.
[david]
2. The number of keys in the server is clearly more for symmetric keys. In
addition, it has to keep track of 'link-id'/key pair which is more difficult
than that of 'device-id' in the case of public keys.
[cliff] Although the public key may be cached in the server, there is no
need to save the PSK for a tunnel at the server, since they have been
delivered to both tunnel ends. If a new PSK is needed, just generate it and
push it out to both ends again. However, the server key storage seems to be
an implementation issue.
--- David
P.S. I agree that when a device been tampered, all the established secured
link to this device are broken for either symmetric or asymmetric keys are
used.
----- Original Message -----
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'david chen'" <ietf_davidchen@hotmail.com>; "Sandy Harris"
<sandy@storm.ca>; "'IPsec WG'" <ipsec@lists.tislabs.com>
Sent: Friday, November 30, 2001 2:49 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)
> This analysis is seriously flawed:
> 1) SPSK or group pre-shared key per box is a bad idea. No security
conscious
> people will adopt this. Because of this serious flaw in assumption,
> all security level comparison are meaningless.
> 2) Once an attacker compromise a box, he has access to either private
> key
or
> the pre-shared key.
> Any communication with the box's partners are compromised, whether
> using
PKI
> or PSK for IKE authentication. Where is the 200% risk come from?
> 3) why each device needs to have 499 public keys? They are contained
> in
each
> box's cert and delivered as part of IKE exchange.
>
> -----Original Message-----
> From: david chen [mailto:ietf_davidchen@hotmail.com]
> Sent: Friday, November 30, 2001 1:15 PM
> To: Sandy Harris; 'IPsec WG'
> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)
>
>
> Here is my observation:
>
> The RSA puliblic/private key (RSA key) is better than symmetric
> pre-shared key (SPSK) in the following way: Suppose both the RSA key
> and SPSK all
using
> centerally managed server in a domain and further assume that the SPSK
> is one for each device (not one for each pair of device). Let's say
> there are 500 devices in this domain: Then there will be 500 keys for
> SPSK so is RSA keys. Each device will either have 499 public keys or
> 499 SPSKs. Given the key management (add/delete/remove) are *almost*
> equal, the SPSK has a not ignorable drawback than RSA Key structure:
> To break RSA key, attacker has
to
> break into the device that hold the private key or break into the
> device that itself is the victim of MIM attack. The device has to
> responsible for its own security. (Given the real world that the
> security of a device are not created equal, this is a reasonable
> requirement)
>
> On the other hand, to break a SPSK, the attacker can choose any of the
> 500 devices to breakin. The risk is much higher for a device due to it
> demand all other participated devices have the same security level.
>
> Sure, the SPSK can increase the number of keys that limited the key to
only
> two parties (and increase the complexicity of the key management) but
still
> it is 200% risk more than RSA key due to it demands the same level of
> security level on peer.
>
>
> --- David
>
>
>
> ----- Original Message -----
> From: "Sandy Harris" <sandy@storm.ca>
> To: "'IPsec WG'" <ipsec@lists.tislabs.com>
> Sent: Friday, November 30, 2001 10:10 AM
> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)
>
>
> > Alex Alten wrote:
> >
> > > I will re-iterate my position. If a network security system is
> > > properly designed then either Public Key or Symmetric/Private Key
> > > cryptography will work fine in establishing trust.
> >
> > So far, so good.
> >
> > > I furthermore claim that Symmetric/Private Key cryptography will
> > > scale to great numbers of users
> >
> > Sorry, but this is nonsense. The classic problem with symmetric
> > crypto is key management. It neither scales well nor works well
> > across
> administrative
> > boundaries.
> >
> > Consider n sites which all want to communicate.
> >
> > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which
> > is known to exactly two players and none of the others. Moreover,
> > you have to communicate those keys securely to the second player in
> > each case, and then keep it secure on both systems.
> >
> > With public key, you need only n key pairs. There is no need to
> communicate
> > keys securely; the system is designed to work even if the enemy
> > knows the public keys. Nor do you have to manage security for
> > multiple keys, or keep track of who each key is shared with. You
> > just need to keep your private key secure, not shared with anyone.
> >
> > Of course you can build a kerberos-like system using symmetric
> > ciphers that has many of the advantages of public key. Using a
> > central key server reduces the number of keys to n client-to-server
> > keys and may simplify management. However, I doubt such a
> > centralised model is appropriate for Internet infrastructure.
> >
> > > and I use the bank ATM secure network using DES as an excellent
> > > example. ...
> >
> > I think that's an irrelevant example. A tightly controlled single
> > purpose terminal-to-mainframe network under a single administrative
> > authority bears no useful resemblanmce to the Internet. Someone gave
> > a good detailed analysis earlier in the thread. You should re-read
> > it.
> >
> > > As far as I'm concerned this should be the end of the discussion
> >
> > I agree, but for opposite reasons.
> >
> > > about whether or not Symmetric/Private Key cryptography can scale
> > > to large numbers of users in an efficient, easy to use by ordinary
> > > people, inexpensive to implement manner and interoperable between
> > > devices made by different manufacturers and maintained by
> > > different organizations. It has been done for the past 20 years by
what
> is
> > > probably the most successful world-wide commercial networked
> > > security
> system.
> > >
> > > Anyone who still claims that Public Key is superior to
> > > Symmetric/Private
> Key
> > > cryptography, or that it is the only way to scale, is a *damn
> > > fool* and
> should
> > > be treated as such.
> >
> > How about "obviously superior for some purposes, including most key
> > distribution applications" and "almost always the best way to build
> > scalable systems"?
> >
> > Methinks you'll consider me a fool. I heartily return the sentiment.
> >
>
Follow-Ups: