GUID registration system

[Hxaltai]

And gpg / pgp is still useless as this does something quite opposite to what we need. It only proves that someone is who they say they are.
ID'ing for admin-lvl on servers is a done thing, see server-unique-guids for that we need no gpg/pgp and spoofing is not really possible with that guid

Server unique GUIDs are just an ugly hack and have a flaw. They don't identify people between servers, which would be useful when you're running multiple servers yourself (you could share the player database) or to discourage known name spoofers (where names aren't protected). I'm all for an RSA GUID system.

[Caveman]

Server unique GUIDs are just an ugly hack and have a flaw. They don't identify people between servers, which would be useful when you're running multiple servers yourself (you could share the player database) or to discourage known name spoofers (where names aren't protected). I'm all for an RSA GUID system.

Just for the record, we are maintaining several servers on different IPs and have yet to encounter the 'Problem' where we had need for that.

If you'd actually followed this thread then you'd know that what you are for is also a failure in itself as the encryption of a guid does not matter if someone does not want to be ID'ed.

[player1]

just to save Caveman from having to constantly repeat himself:

YOU CAN'T ID PLAYERS WHO DON'T WANT TO BE ID'd!!!

outlawing guns means only outlaws have guns

[Hxaltai]

If you'd actually followed this thread then you'd know that what you are for is also a failure in itself as the encryption of a guid does not matter if someone does not want to be ID'ed.

If you'd actually read my post then you'd notice no implication of such a possibility. What I was for is a GlobalUID system for those players that want to be positively identified, in place of the Server-Local Unique IDentifier.

Just for the record, we are maintaining several servers on different IPs and have yet to encounter the 'Problem' where we had need for that.

There's never a problem if you're working around it actively.

[Caveman]

Dude, get a clue.
As soon as there is (again) a guid that is transmitted to a server it is compromised.
And no matter if you only send a hash or the guid itself.

If you find a way to stop malicious server admins to 'steal' the hash / guid and to mod an Open Source client, your idea might have some worth.

Until then it's just half baked BS that is not needed and more work than it's worth.

[Hxaltai]

Dude, get a clue.
As soon as there is (again) a guid that is transmitted to a server it is compromised.
And no matter if you only send a hash or the guid itself.
If you find a way to stop malicious server admins to 'steal' the hash / guid and to mod an Open Source client, your idea might have some worth.
Until then it's just half baked BS that is not needed and more work than it's worth.

I see you have no idea how an RSA challenge-response system would work. The private key or hash thereof is never sent to the server. There is absolutely no way to steal the private key short of actually hacking the client.

Background:
RSA is an asymmetric key system, where you compute a pair of keys, and you can encrypt stuff with one key that is decryptable with the other.

It works like this:
- client sends pubkey to the server, that becomes the users GUID
- server sends a randomly generated challenge string to the client
- client encrypts the challenge with privkey and sends the response to the server
- server decrypts the response with pubkey and checks if it's identical to the challenge string, doesn't let the player in if they differ

The privkey is never transmitted, there is no way to infer privkey from pubkey in reasonable time, or compute a new privkey that works with pubkey. You can't just spoof the pubkey because no server will let you in. You can't spoof the privkey because you don't have it.

This is the simplest scenario, a scenario hardened using common cryptographic practices would work very similarly though.

[kevlarman]

19:14  kevlarman> timbo, would you be against adding something a bit more secure
than cl_guid?
19:14  kevlarman> (assuming someone else did the work of course)
19:15 @Timbo> is it really that insecure?
19:16  kevlarman> well with cl_guidserveruniq it isn't
19:16  kevlarman> but then you can't even have 2 servers sharing admins
19:17  kevlarman> we have 2 servers running on the same box and we have to give
everyone admin by hand
19:17 @Timbo> cl_guidserveruniq should be the default imo
19:18  kevlarman> probably yeah
19:18 @Timbo> by which i mean you can't turn it odd
19:18 @Timbo> off
19:18  kevlarman> that might be excessive
19:19  kevlarman> i was thinking about grabbing an rsa implementation from opens
sh or something
19:19 @Timbo> i'm definitely against that
19:19  kevlarman> and adding a client command/game command to avoid breaking any
thing
19:19  kevlarman> any particular reason?
19:19 @Timbo> there is a limit to how important admin on a computer game server
is :)
19:19 @Timbo> RSA is totally overkill

looks like we won't be getting anything like digital certificates to identify players :(

[player1]

ty

[FooBar]

there is a limit to how important admin on a computer game server is

Ha!  Yes, that's exactly why I haven't tried an implementation myself.  Well, that and my thesis.  Such as it is.

Caveman, you never really understood the point of my post.  I understand that you cannot ID players who don't want to be ID'ed.  My post was about providing unique, global, non-spoofable, totally secure ID for players who DO want to be IDed.  And as Hxaltai stated, a private-public key pair would work extremely well for that.  A side effect would be that every server could also have such a unique ID.

But as Timbo says, it's probably not important enough to be worth the trouble.  

[Caveman]

And once again I need to state that it's only those that do not want do be ID'ed are the problem. For the rest we do already have a way that is 99% secure.

[kevlarman]

And once again I need to state that it's only those that do not want do be ID'ed are the problem. For the rest we do already have a way that is 99% secure.

it's still a pain to lose your entire admin list when your server moves....

[benmachine]

Even if Timbo doesn't want it in mainline Tremulous, I think we should see what can be done with GPG for several reasons:
1. it's much easier to say 'yes, let's include that' than 'yes, let's include what that might eventually be'
2. the rate of uptake might persuade him that lots of people like it and use it, and it would therefore be a valuable addition to the codebase
3. most people aren't using "official" code on their servers and clients anyway, if we manage to contain a modification to client binary/game.qvm (like tjw did with g_admin), then the transition should be nice and smooth and before you know it, it will be everywhere.

[sleekslacker]

Honestly, I don't see what's Timbo's reason for not accepting a number of things in the code ( libvorbis for example ). Go on and see what you can do with GPG and let's see if the public will be smart enough to use it. Thanks to GPL, the worst it can bring us is a fork of the project.

[next_ghost]

Erm, you do realize that however the ID system works, the server part must finish in much less than 50ms? I'm not really sure GPG can do that, especially when you have multiple keys.

[Caveman]

Why must it be done in 50ms?
To get pgp/gpg included you'd have to rewrite server and client code anyhows, so 'just' remove this timelimit... (Yes I know that WILL open Pandora's Box)

[next_ghost]

Why must it be done in 50ms?
To get pgp/gpg included you'd have to rewrite server and client code anyhows, so 'just' remove this timelimit... (Yes I know that WILL open Pandora's Box)

50ms = 20 server frames per second. You can't remove that limit without freezing the server for a few frames (or worse, seconds) and lagging everyone. It could be possible to use separate thread for authentication though. But I'm sure nobody would want to debug that.

[Caveman]

50ms = 20 server frames per second. You can't remove that limit without freezing the server for a few frames (or worse, seconds) and lagging everyone...

I still don't get your argument, as I have no clue of the code, you might want to take me slowly through this argument.

I also don't understand your explaination of how 50ms can be equal to 20sfps.

[next_ghost]

I still don't get your argument, as I have no clue of the code, you might want to take me slowly through this argument.

I also don't understand your explaination of how 50ms can be equal to 20sfps.

The server runs in a single thread in one huge loop. In general, one loop step looks like this: read incoming packets and parse client commands, calculate new gamestate, send the gamestate to clients, rinse & repeat. Right now, the authentication through GUID takes place during packet reading and client command parsing.

The standard server setting is 20fps and when a frame is finished, the server will sleep until it's time to calculate the next frame. That means that every frame takes 50ms (because 50ms * 20 = 1000ms = 1s).

If you don't finish the frame in less than 50ms, the server won't start sending gamestate updates in time and the game will lag.

[Hxaltai]

...

I see your point. I made a benchmark with python's M2Crypto based on OpenSSL and it takes about 37ms to encrypt or decrypt using RSA-2048bit with C2D at 2.13GHz and 51ms at 1.6GHz. While it is quite a long time I doubt it would present itself as a problem, because cryptographic operations need to be done only at a new connection setup. I'm not sure whether the connection is reinitialized across map reloads, but even if it was the case, identity could be somehow cached.
Nevertheless if we were concerned with a possible DoS attack exploiting the overhead of cryptography we can always throw it into a separate thread and have the client wait for a connection a moment longer.

[FooBar]

Yes, I wasn't really considering that EVERYTHING would be encrypted or authenticated... My only interest in GPG was that it would provide a GUID (the public key) that could not possibly be spoofed or stolen. I envisioned that at connection time, and at the start of every map, there would be a little interaction between server and client.  In this interaction:[list=1]

• The client would prove it was the true owner of its public key,
• The server would prove that it was the true owner of its public key; and
• All game traffic would proceed as usual (without continual verification), just using the public key as the GUID.[/list:o]As far as I know, a public key could be trivially dropped in to replace the current data in the GUID.  The only difference is, I think a public key contains more bytes of data, which I guess would mean a slightly larger packet?
  
  Then, for example, SST would know that I was the same FooBar who signed on yesterday.  And I would know that Fragify (New York) was a totally different server from Fragify (Virginia), and not just the old server in a new location.
  
  The only reason to (a) continually authenticate, or even (b) encrypt all game traffic, would be if you wanted to [list=a]
• Prevent some kind of insane man-in-the-middle spoofing; or
• Keep any hypothetical internet eavesdroppers from learning you just got pwned.[/list:o]Unless we want to introduce secure online shopping in Tremulous.
  
  I thought that mandatory GUIDs (always-on-GUID by default), combined with public-key-based GUIDs, would make it easy, for example, to deal with multiple players from the same IP address, and various other admin situations that can be a little tricky.
  
  And of course, with a global GUID registration system GPG would probably be necessary, in the long run, to prevent rampant spoofing from making the system worthless.  So that brings the whole conversation back on-topic.  
  
  But I'm not really interesting writing it,  since as Timbo says, it's a lot of trouble and it may not really be worth it.  Oh, someday if I'm really bored I may take a stab at it, but not right at the moment.    I just wanted to know if anyone had seriously talked about it.  And now we have!

[/dev/humancontroller]

qvms don't get linked against the crt

Timbo just added isalnum() to the Q3 code.
http://svn.icculus.org/quake3/trunk/code/qcommon/q_shared.h?r1=1168&r2=1185&p1=trunk/code/qcommon/q_shared.h&p2=trunk/code/qcommon/q_shared.h

[Caveman]

is there anything older than the news from last week?

[Foobicam]

Yes, I wasn't really considering that EVERYTHING would be encrypted or authenticated... My only interest in GPG was that it would provide a GUID (the public key) that could not possibly be spoofed or stolen.

The standard way to protect EVERYTHING (as in IPSec or TLS) is to use public key agreement protocol (10's of milliseconds) to establish a session key, and then use the session key to authenticate traffic using HMAC (sub-milliseconds).  Not that there is a crying need to authenticate normal player traffic, but all privileged (admin) actions would benefit from session authentication.

Caveman makes lots of good points, but this:
A failsafe way to ID a player, one that can not be spoofed.
is not one of them.  Public key authentication is a failsafe way to ID a player that cannot be spoofed, unless you can hack that player's computer to steal his private key. USB tokens or smartcards address that problem.  Because Tremulous doesn't have much of intrinsic value (admin privileges are fun, but don't hit you in the pockebook like online banking or shopping) there is not a huge incentive to spoof an existing ID.  The problem addressed by invites, whitelists, eBay-like reputations, pay-per-ID, etc, is the ability to mint an unlimited number of new IDs at very low cost.  As long as minting IDs is easy, there is little incentive for a griefer to spoof someone else's ID.  If Tremulous had a mechanism for adding value to IDs, griefers would have more incentive to steal an existing ID rather than minting a new one, and authentication would then be needed.

So what is an appropriate way to add value to Tremulous IDs?  Reputation, in my opinion.  This would involve:

* Each server operates a reputation system (like Dretch*Storm's experience points - XP) according to its own formula.  Griefing would be penalized by reducing XP for successful votekicks, admin kicks, and bans of various duration.  The server operator could link in-game reputations with forum reputations (post counts or member ranks) to make it more difficult to quickly mint new in-game IDs.  A server could require pay for play (although I certainly wouldn't pay simply for the privilege of avoiding griefers and I doubt such a server would succeed).  Much better would be inferred payment: require registration through an institutional email account (isp-provided, .edu or corporate, but not hotmail/gmail/yahoo).  A griefer might have access to a few such addresses (Verizon permits 8 email addresses per account) but not an unlimited supply.

* Each server publishes its reputations using a standard (to-be-defined) interface which any other server could query.  There is no need for a centralized "ban" server, the existing master server allows a server to find all other servers that send a heartbeat.  The reputation query would contain a GUID; the response would contain the public key used to authenticate that GUID and the reputation info.

* Each server would collect reputations from every other server it cared to check (valuing the opinions of some servers more than others).  It would then make a decision to admit or deny a player using its own criteria.

A crucial point of this scheme is federation: there is no central authority for making ban decisions.  Instead there is an information sharing federation in which every server is sovereign: it publishes what it chooses to publish, and makes whatever decisions it wishes based on information published by others.

A second crucial point is that because new GUIDs can be minted and because, if per-server GUIDs are used, a player can choose which GUIDs to disclose and thus which servers' reputation info can be linked to the player, THERE IS NO VALUE in attempting to rely on negative reputations as a reliable way of detecting griefers.  Caveman is absolutely correct on this point: a GUID does not ID a player unless he wants it.

So why bother?

Because if there are a few well-admined servers that limit GUID minting somehow (e.g. by requiring registration from a paid email address) and choose to share their users' XP info, then they would be able to leverage each others efforts.   Perhaps the federation would grow in popularity, or perhaps good (well-intentioned, whether skilled or noob) players would migrate to more griefer-friendly servers.  Hard to say without trying.

[tuple]

The problem with user identification is that it really only works with users who WANT to be identified.  Tracking a user who does not want to be identified is not easy, and is impossible for a game server.

The problem with this federation reminds me of an old mad magazine joke.

A man walks into an office and up to the front desk.  "I'd like to attend trucking school." He says.
"Are you a member of the truckers union?" The person behind the desk asks.
"No"
"You have to be a member of the truckers union to attend trucking school."
"ok, can I join the truckers union?"  The man asks.
"Are you a trucker?"  The desk clerk asks.
"umm, no"
"You have to be a trucker to join the truckers union."