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.
> > >
> >
>