[MUD-Dev] strong encryption for authentication

[J C Lawrence]

On Fri, 13 Jul 2001 13:24:02 -0600 
Kwon Ekstrom <justice at softhome.net> wrote:

> I'd like to point out that this thread seems to be degenerating,
> the points of encryption I've noticed is:

<deletia analytical listing>

> It pretty much falls down to these categories, a variety of ways
> to limit the overhead have been mentioned, most cost $$$ that many
> mud developers don't have.  While I beleive that encryption would
> be a nice addition for muds to use in order to protect your
> password for instance, I don't beleive it should be in full time
> usage, or even a requirement.  

  Aside: For the sake of this discussion I'm also going to generally
  ignore and avoid the entire question of PKI and key/certificate
  distribution/revocation.  We are implicitly talking about a
  scenario where the end nodes are not trustworthy, and where we
  explicitly cannot rely on either private or negotiated streaming
  cipher keys to neither be exposed, copied, distributed, published
  or otherwise invalidated.  I'll comment on this a bit more later,
  but examining this aspect in depth would take more effort than I'm
  interested in right now.

The same basic questions as for any other security question apply:

  What are the risks?

  What are the costs?

  What are the gains?

In the case of using an encrypted transport the costs are fairly
clear cut: added complexity to both your software and SysAdm load,
and computational overhead (with a second order expense of potential
scalability problems).

The risks and gains analysis depends on the answer to a more
interesting question: 

  Is this an encrypted protocol, or is it an encrypted transport?

More specifically: 

  Are you tunneling cleartext packets under an encrypted VPN or are
  you sending otherwise-normal packets with encrypted payloads?

The difference is critical as it changes the basic risk model.  Much
like machine gun tracers, VPN's go both ways.  Compromises of the
VPN exposes all interfaces and networks that comprise that network.
All that is required to compromise a VPN is compromise of a member
node.  

  <deletia rant against criminally deceptive security vendor
  advertising>

Establishing even a point-to-point VPN is attractive from a design
perspective: It retains the crypto supports while reducing
complexity and crypto exposure from every single protocol stream
that you transfer.

  Note that limiting your VPN's to point-to-point links doesn't
  limit the exposure.  It removes the risk that compromise of client
  a system exposes all interfaces on all other client systems
  playing the game.  It doesn't remove the risk that compromise _OR_
  faulty configuration of the core node (presumably one of your game
  servers) also exposes all interfaces on all other client systems
  playing the game

The next problem is that all of this analysis is resting on
quicksand.  The client is in the hands of the enemy.  It not only
can't be trusted, we can implicitly assume that it has not only been
compromised by the player, but also by any other party with even a
mild interest.

  I did an experiment a couple days ago and installed Windows 2K on
  a test system that had a 'net routable IP.  Suffice to say that
  the CD was not out of the drive before the box had been port
  scanned, cracked and a root kit installed (snort on a shared net
  segment showed me the whole thing). Note: This is not a
  condemnation of Windows, but an observation of 'net realities.
  A mate recently installed Linux on a box, didn't know how to
  secure it, and had it cracked sometime that evening (~8 hours
  later).  

  End user systems are not only implicitly untrustworthy, but
  (most?)  end users have no particular willingness or interest in
  keeping their home desktops secure.

Which in turn calls into question the whole crypto point.  

  For the sake of argument I'll assume that your basic crypto
  implementation is secure and your models sound.  In practice this
  is a fairly large concession, but well proven frameworks are
  becoming well enough known and available as to START to suggest
  this may be a moot point in a few years.

What would crypto buy you given that the client system is both
untrustworthy both by the client user and you?

  1) An intermediate transit node which passes your packet streams
  cannot decrypt the traffic unless it also has privileged access
  to the client (I'll assume your servers are secure and
  appropriately configured).

  2) An arguably false sense of trust by your users in the
  security/confidentiality of their game communications/actions.

  3) An arguably false sense of trust by your users in the
  verisimilitude of what their game client presents to them as
  versus what is actually present on the server.

  4) The increased possibility of iniquitous (due to difficulty in
  detection) of man-in-the-middle attacks.

  5) Possible exposure to litigation for second order effects of
  compromise of your crypto arrangements (consider a game where some
  players run profitable businesses in-game, and also lose
  significant $$$ due to communication compromises (note that
  disclaimers and abnegation of responsibility clauses don't always
  come out in court as you'd think they might)).

Not a whole lot of profit there, and some of the profit counts more
as risks.

Which rolls us nicely back to the PKI problem along with key
security.  If you are going to attempt to defend yourself from
main-in-the-middle attacks you're stuck doing client-side
certificates which means that you then end up running a root CA and
then doing mutual authentication in building the pipes.  Cute,
except that the private keys on the client aren't trustworthy.  The
effort required to replace them with a compromised set and then
insert a man-in-the-middle is minor at best, trivial at worst.

> The problem with worrying about packet sniffing is almost
> irrelevant, 99.9% of the internet community doesn't have the
> required knowledge or tools, even if they are in a position to use
> them.

The problem is that while 99% doesn't, perhaps 0.5% not only do, but
they can trivially automate their work and thus manipulate large
numbers of systems both automatically and autonomously.

I did an address block scan of a local ISP a couple months ago using
nmap.  Suffice to say that out of the ~900 Windows boxes that nmap
identified, more than 400 showed clear signs of having been cracked.
Typically such systems are manipulated via IRC messages (once
cracked the systems auto-login to pre-canned IRC channels and then
send and received instructions there).  Extending such a system to
enclude and incorporate a successful game system would neither be
particularly difficult or unrewarding.

See Gibson's recent articles for discussion of the background
techniques:

  http://grc.com/dos/grcdos.htm

ObNote: Steve is technically correct in his assertions.  His
conclusions equally technically correct but his evaluation of those
conclusions are at best injudicious and at worse rabble rousing.

> It's my understanding that in order to intercept packets you must
> be on the same local network, or en-route of the network.

Correct.

> The gains for the average server are small but can have dramatic
> resource overhead which can and will increase maintenance costs.

Yup, which is not to say that the gains in authentication
reliability are not valuable, or in certain cases (niche anyone?) 
convincing.

This is also not to say that all edge nodes are necessarily
untrustworthy.  If you have means to select your player base in
interesting fashions you may also be able to select for players that
are more or less trustworthy.

> As for being able to take credit card information and other
> "secure"... I think that can best be handled by a web form using
> https.  

Note that this uses server-side authentication only and relies on
use of secret root CA keys (verisign, baltimore, thawte, etc) to
prevent MiM attacks.  As such its valuable for posting data to the
central server, not for secure distribution of data to edge nodes.

> And as mentioned it'd be wonderful for authentication.

Please make sure you examine the underlieing PKI and key
distribution questions.  They are not trivial problems.

> As every other tool, it's just a tool, use it when you need it,
> but otherwise put it back in the box.

<nod>

--
J C Lawrence                               ("`-''-/").___..--''"`-._         
---------(*)                                 `6_ 6  )   `-.  (     ).`-.__.`)
claw at kanga.nu                               (_Y_.)'  ._   )  `._ `. ``-..-'  
http://www.kanga.nu/~claw/                _..`--'_..-_/  /--'_.' ,'         
I never claimed I was human             (il),-''  (li),'  ((!.-'           
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev