Key Based Authentication - Revision history

Cadillac at 17:37, 23 August 2021

2021-08-23T17:37:44Z

← Older revision		Revision as of 13:37, 23 August 2021
Line 105:		Line 105:
	* if two different users (playing from different machines) talk about Luke-Jr, they don't neccessarily mean the same player. This even applies to in-game chat.		* if two different users (playing from different machines) talk about Luke-Jr, they don't neccessarily mean the same player. This even applies to in-game chat.
	[[User:Meriton\|Meriton]] 14:59, 7 March 2006 (CST)		[[User:Meriton\|Meriton]] 14:59, 7 March 2006 (CST)

			[[Category:Development]]

Luke-Jr: /* Alternative: Nicknames for Authorities */

2006-03-08T02:43:55Z

Alternative: Nicknames for Authorities

← Older revision		Revision as of 22:43, 7 March 2006
Line 51:		Line 51:

	:: In practise, the auth server signs a tuple (<user name>, <authority key>, <desired authority name>) with its secret key. [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)		:: In practise, the auth server signs a tuple (<user name>, <authority key>, <desired authority name>) with its secret key. [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

			:: Player keys would ''still'' be necessary to enable the ability for a player to change their authority. --[[User:Luke-Jr\|Luke-Jr]] 20:43, 7 March 2006 (CST)

			:: The reason for the player's authority server (or one delegated by it) to do the name resolution is to preserve the same mapping across different clients (Uncle Joe scenario). The same applies to resolving an authority name. --[[User:Luke-Jr\|Luke-Jr]] 20:43, 7 March 2006 (CST)

	When the game server verifies the user is in posession of such a partial/temporary key, it also gets to know the user name, the authority's public key and its desired authority name and can pass that to the other connected clients.		When the game server verifies the user is in posession of such a partial/temporary key, it also gets to know the user name, the authority's public key and its desired authority name and can pass that to the other connected clients.

Meriton: name resolution like DNS?

2006-03-08T01:42:32Z

name resolution like DNS?

← Older revision		Revision as of 21:42, 7 March 2006
Line 41:		Line 41:

	The goal is to provide display names of the form <user name>@<authority name>. Since each authority can prevent user name collisions between different users of the same authority, only authority name collisions need to be resolved. Since there will probably be less authorities than players, this should be easier.		The goal is to provide display names of the form <user name>@<authority name>. Since each authority can prevent user name collisions between different users of the same authority, only authority name collisions need to be resolved. Since there will probably be less authorities than players, this should be easier.

			:: In a nutshell, this looks like DNS to me. What about using "." instead of "@" to seperate name from authority? Also, we might consider to allow more than 2 hierarchy levels. [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

	It also provides better consistency of names. Say, we have tho authorities and four players, one luke and one meriton per authority. For z-man, the players will be named luke, luke(2), meriton and meriton(2) in the nickname resolver scheme. For lucifer, using a different name resolver, they'll be named the same, but in different order: luke, luke(2), meriton(2) and meriton, and when z-man and lucifer are talking about them, they have to remember two possible name replacements.		It also provides better consistency of names. Say, we have tho authorities and four players, one luke and one meriton per authority. For z-man, the players will be named luke, luke(2), meriton and meriton(2) in the nickname resolver scheme. For lucifer, using a different name resolver, they'll be named the same, but in different order: luke, luke(2), meriton(2) and meriton, and when z-man and lucifer are talking about them, they have to remember two possible name replacements.

	In the alternative scheme, if the two authorities have different names, say fe and bot, the four users will be named luke@fe, luke@bot, meriton@fe and meriton@bot for everyone. And that's a likely scenario, as authority name collisions are easier to avoid from the start than nickname collisions. If the two authorities have the same desired name fe, the players will be named luke@fe, meriton@fe, luke@fe(2) and meriton@fe(2). If z-man now is talking with lucifer about the players, they have only to memorize one possible swapping, whether z-man's fe is lucifer's fe or fe(2).		In the alternative scheme, if the two authorities have different names, say fe and bot, the four users will be named luke@fe, luke@bot, meriton@fe and meriton@bot for everyone. And that's a likely scenario, as authority name collisions are easier to avoid from the start than nickname collisions. If the two authorities have the same desired name fe, the players will be named luke@fe, meriton@fe, luke@fe(2) and meriton@fe(2). If z-man now is talking with lucifer about the players, they have only to memorize one possible swapping, whether z-man's fe is lucifer's fe or fe(2).

	The authority name resolution can be done on the client locally without need of an extra server (further implementation simplification) The rest of the protocol needs minor adjustments, but only insofar as different data needs to be sent. Instead of player keys, which are useless here, the authority has just one master public/private key pair. The temporary/partial keys delivered to the players also contain the restriction to the player's username: they don't say "This key is equivalent to the master key", but "This key is equivalent to the (not really existent) sub-key of user <name> of the master key of authority <desired authority name>". When the game server verifies the user is in posession of such a partial/temporary key, it also gets to know the user name, the authority's public key and its desired authority name and can pass that to the other connected clients.		The authority name resolution can be done on the client locally without need of an extra server (further implementation simplification) The rest of the protocol needs minor adjustments, but only insofar as different data needs to be sent. Instead of player keys, which are useless here, the authority has just one master public/private key pair. The temporary/partial keys delivered to the players also contain the restriction to the player's username: they don't say "This key is equivalent to the master key", but "This key is equivalent to the (not really existent) sub-key of user <name> of the master key of authority <desired authority name>".

			:: In practise, the auth server signs a tuple (<user name>, <authority key>, <desired authority name>) with its secret key. [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

			When the game server verifies the user is in posession of such a partial/temporary key, it also gets to know the user name, the authority's public key and its desired authority name and can pass that to the other connected clients.

	The clients now know the tuple (<user name>, <authority key>, <desired authority name>) of all other players and can indirectly verify that the player identified by that is indeed playing by sending a challenge to the other client indirectly over the server.		The clients now know the tuple (<user name>, <authority key>, <desired authority name>) of all other players and can indirectly verify that the player identified by that is indeed playing by sending a challenge to the other client indirectly over the server.

			:: Isn't it typically the case that the player trusts the server he is playing on? If so, it would be ok if the game server verified the keys. I'd prefer that, since if the game server discovers that an id is fake, he can kick the player. What should a client do if it discovers that the id is fake? [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

	Now comes the authority name resolving: The client keeps a list of all authority keys it has encountered and the names it has assigned to them. If the desired authority name is already used by another key, the desired name is altered. Then, the name is saved and associated with the authority key for the future. Then, the name <user>@<authority> is assembled and displayed.		Now comes the authority name resolving: The client keeps a list of all authority keys it has encountered and the names it has assigned to them. If the desired authority name is already used by another key, the desired name is altered. Then, the name is saved and associated with the authority key for the future. Then, the name <user>@<authority> is assembled and displayed.

			:: Doesn't that merely shift the problem of only locally unique names from players to authorities? [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

	A list of known authorities with their keys and names can be distributed with the game and on request by the master server, giving protection against name grabbing to the most popular authorities. With a player database, this would be hardly possible.		A list of known authorities with their keys and names can be distributed with the game and on request by the master server, giving protection against name grabbing to the most popular authorities. With a player database, this would be hardly possible.

			:: Why don't we take this a step farther and create a root authority that manages all authority ids like the authorities manage player id's? This enables better code reuse. [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

	Special care has to be taken here for locally authorized players, those players who hold their own key and don't use an authority server. Assigning an authority that only holds a single player a name does not make too much sense. Those players should not get any form of nickname protection as the abuse potential is just too big in either scheme.		Special care has to be taken here for locally authorized players, those players who hold their own key and don't use an authority server. Assigning an authority that only holds a single player a name does not make too much sense. Those players should not get any form of nickname protection as the abuse potential is just too big in either scheme.

			:: Correct. Since their names lack an @, they can easily be told apart from registered players. Similarly, authorities not certified by the root authority should be permitted, but somehow marked, so that people know that the authority name (and by consequence, the player identifier) need not be globally unique. [[User:Meriton\|Meriton]] 19:42, 7 March 2006 (CST)

	== Attack Vectors ==		== Attack Vectors ==

Z-man: /* Displaying Names For Players (Name Resolution) */

2006-03-07T23:11:55Z

Displaying Names For Players (Name Resolution)

← Older revision		Revision as of 19:11, 7 March 2006
Line 37:		Line 37:

	Upon seeing PlayerKey[68b329da9893e34099c7d8ad5cb9c940] for the first time, a client will ask their name resolution server to lookup the key. If the key is known, the name associated with it will be displayed. If it is not, the client then asks the game server to resolve the key's name for them. The game server will send back the name requested by the key. The client will now inform its name resolution server of this key<->name association, and the server will verify that the name does not conflict with another key. If there is a conflict, the server will modify the name (possibly by appending a number) and inform the client of the changed name.		Upon seeing PlayerKey[68b329da9893e34099c7d8ad5cb9c940] for the first time, a client will ask their name resolution server to lookup the key. If the key is known, the name associated with it will be displayed. If it is not, the client then asks the game server to resolve the key's name for them. The game server will send back the name requested by the key. The client will now inform its name resolution server of this key<->name association, and the server will verify that the name does not conflict with another key. If there is a conflict, the server will modify the name (possibly by appending a number) and inform the client of the changed name.

			== Alternative: Nicknames for Authorities ==

			The goal is to provide display names of the form <user name>@<authority name>. Since each authority can prevent user name collisions between different users of the same authority, only authority name collisions need to be resolved. Since there will probably be less authorities than players, this should be easier.
			It also provides better consistency of names. Say, we have tho authorities and four players, one luke and one meriton per authority. For z-man, the players will be named luke, luke(2), meriton and meriton(2) in the nickname resolver scheme. For lucifer, using a different name resolver, they'll be named the same, but in different order: luke, luke(2), meriton(2) and meriton, and when z-man and lucifer are talking about them, they have to remember two possible name replacements.

			In the alternative scheme, if the two authorities have different names, say fe and bot, the four users will be named luke@fe, luke@bot, meriton@fe and meriton@bot for everyone. And that's a likely scenario, as authority name collisions are easier to avoid from the start than nickname collisions. If the two authorities have the same desired name fe, the players will be named luke@fe, meriton@fe, luke@fe(2) and meriton@fe(2). If z-man now is talking with lucifer about the players, they have only to memorize one possible swapping, whether z-man's fe is lucifer's fe or fe(2).

			The authority name resolution can be done on the client locally without need of an extra server (further implementation simplification) The rest of the protocol needs minor adjustments, but only insofar as different data needs to be sent. Instead of player keys, which are useless here, the authority has just one master public/private key pair. The temporary/partial keys delivered to the players also contain the restriction to the player's username: they don't say "This key is equivalent to the master key", but "This key is equivalent to the (not really existent) sub-key of user <name> of the master key of authority <desired authority name>". When the game server verifies the user is in posession of such a partial/temporary key, it also gets to know the user name, the authority's public key and its desired authority name and can pass that to the other connected clients.

			The clients now know the tuple (<user name>, <authority key>, <desired authority name>) of all other players and can indirectly verify that the player identified by that is indeed playing by sending a challenge to the other client indirectly over the server.

			Now comes the authority name resolving: The client keeps a list of all authority keys it has encountered and the names it has assigned to them. If the desired authority name is already used by another key, the desired name is altered. Then, the name is saved and associated with the authority key for the future. Then, the name <user>@<authority> is assembled and displayed.

			A list of known authorities with their keys and names can be distributed with the game and on request by the master server, giving protection against name grabbing to the most popular authorities. With a player database, this would be hardly possible.

			Special care has to be taken here for locally authorized players, those players who hold their own key and don't use an authority server. Assigning an authority that only holds a single player a name does not make too much sense. Those players should not get any form of nickname protection as the abuse potential is just too big in either scheme.

	== Attack Vectors ==		== Attack Vectors ==

Z-man: /* Temporary Private Keys */

2006-03-07T22:25:36Z

Temporary Private Keys

← Older revision		Revision as of 18:25, 7 March 2006
Line 3:		Line 3:
	== Key Requirements ==		== Key Requirements ==
	=== Temporary Private Keys ===		=== Temporary Private Keys ===
	It must be possible to generate a subset of a private key that only works for a certain period of time.		It must be possible to generate a subset of a private key that only works for a certain period of time. This may be, for example, a data structure containing the public keys A and B and an expiration date, all signed with the private key belonging to A, that says the holder of the private key belonging to B is the person identified originally by the A key pair.

	=== Authority Chain ===		=== Authority Chain ===

Meriton: /* impersonating registered players */

2006-03-07T20:59:56Z

impersonating registered players

← Older revision		Revision as of 16:59, 7 March 2006
Line 64:		Line 64:

	Solution: since names are not themselves registered, this is not a problem. Presuming the players have all seen the real "Luke-Jr" before, any conflicting player would automatically be shown as "Luke-Jr(2)" or such.		Solution: since names are not themselves registered, this is not a problem. Presuming the players have all seen the real "Luke-Jr" before, any conflicting player would automatically be shown as "Luke-Jr(2)" or such.

			Critique of the solution:
			* if a user uses a different installation of armagetron, he uses a different set of name<->key associations, therefore the Luke-Jr he sees while at Uncle Joe's really has nothing to do with the Luke-Jr he met while playing at home.
			* if two different users (playing from different machines) talk about Luke-Jr, they don't neccessarily mean the same player. This even applies to in-game chat.
			[[User:Meriton\|Meriton]] 14:59, 7 March 2006 (CST)

Luke-Jr: /* impersonating registered players */

2006-03-07T01:12:38Z

impersonating registered players

← Older revision		Revision as of 21:12, 6 March 2006
Line 62:		Line 62:
	The other players on that server will resolve the public key to the display name "Luke-Jr".		The other players on that server will resolve the public key to the display name "Luke-Jr".
	* harass people		* harass people

			Solution: since names are not themselves registered, this is not a problem. Presuming the players have all seen the real "Luke-Jr" before, any conflicting player would automatically be shown as "Luke-Jr(2)" or such.

Meriton: how to impersonate Luke-Jr

2006-03-06T20:22:16Z

how to impersonate Luke-Jr

← Older revision		Revision as of 16:22, 6 March 2006
Line 54:		Line 54:

	The authentication server cannot be faked without stealing its private key.		The authentication server cannot be faked without stealing its private key.

			=== impersonating registered players ===

			* set up your own auth server, create a user named "Luke-Jr"
			* get an identity for that user from that server
			* use that identity to log into a game server
			The other players on that server will resolve the public key to the display name "Luke-Jr".
			* harass people

Luke-Jr at 14:28, 6 March 2006

2006-03-06T14:28:47Z

New page

This page is intended for fleshing out the details of a simple authentication scheme.

== Key Requirements ==
=== Temporary Private Keys ===
It must be possible to generate a subset of a private key that only works for a certain period of time.

=== Authority Chain ===
Each key can have controller keys (which can act in place of the key for tasks such as issuing a new key to replace it, revoking it, etc) and controlled keys (to which it can act the same).
An example of this could be a chain of keys:
* Armagetron Advanced Emergency Rescue Key -- entrusted to a secure, offline server (or perhaps segmented in pieces across multiple) for safekeeping in case an authentication server has a disaster. It can be used to issue a replacement Authentication Server Key should it be lost, or revoke it should it be stolen.
* Authentication Server Key -- a master key for an authentication server. It can issue replacement player keys for any players under its control as well as revoke player keys should they be stolen. If the administrator of the authentication server deems the AAERK to be untrustworthy, he can revoke its authority over the ASK.
* Player Key -- this represents a player and is to be used for keeping stats, preventing name conflicts, etc. It can sign and decrypt game server challenges. If the player determines his authentication server to be untrustworthy, or simply wishes to move to another authentication server, he can add a new ASK's authority over his key and then revoke the old ASK's authority over it.

== The Authentication ==

* The client sends the login information (username and password) via a hereby-undefined (encrypted) method to the authentication server.
* The authentication server checks this information and, if valid, sends the client either a temporary or permanent (determined by player's request) private key representing their player, along with their public key. It also sends a name resolution URI, as detailed in the appropriate section.
* The client sends its public key on to the game server.
* The game server encrypts a random session identifier, along with its identity (name, host, possibly public key) to the player's private key.
* The client decrypts this data and confirms the server's identity.
* The client sends the session identifier back to prove that it holds the key advertised.
* The server now knows that the client indeed represents the player it claims to.

== Stats and Conversation ==

The game server deals primarily with a public key or, in the case of an anonymous player, a guest name, which is enclosed in double-quotes.
All conversation and stats are recorded by this identifier.
For example, when sending a chat message to another player, the server will transmit something along the lines of: PlayerKey[68b329da9893e34099c7d8ad5cb9c940] says, "Hi!"

== Displaying Names For Players (Name Resolution) ==

Obviously, no human wants to see
"PlayerKey[68b329da9893e34099c7d8ad5cb9c940]". To deal with this matter, when a player is authenticated, they receive a name resolution URI from their authentication server. This URI can be a variety of possible addresses:
* aanameres://68b329da9893e34099c7d8ad5cb9c940@auth.aa.net -- The player has their own set of key<->name associations.
* aanameres://auth.aa.net -- The player shares their key<->name associations with others on auth.aa.net
* aanameres://central.aadv.org -- The player shares their key<->name associations with others on central.aadv.org, which need not be their authentication server

Upon seeing PlayerKey[68b329da9893e34099c7d8ad5cb9c940] for the first time, a client will ask their name resolution server to lookup the key. If the key is known, the name associated with it will be displayed. If it is not, the client then asks the game server to resolve the key's name for them. The game server will send back the name requested by the key. The client will now inform its name resolution server of this key<->name association, and the server will verify that the name does not conflict with another key. If there is a conflict, the server will modify the name (possibly by appending a number) and inform the client of the changed name.

== Attack Vectors ==

=== The Phishing Server ===

I can't set up a server to permanently steal identities, but I can do the following:
* I set up an innocently looking server and have a client in the background
* I wait for a victim to connect
* I connect my client to some other server that uses authentication, logging in as the same user
* I pass through the authentication verbatim
* I'm logged in as my victim. Mwahaha!

Countermeasure: When the client decrypts the server's session key, it also decrypts the server's identity which can include its name and allowed list of IP addresses and/or hostnames. If the IP address and/or hostnames do not match, or the player does not recognize the human-readable server name, the attack is prevented.

=== Faking the Authentication Server ===

The authentication server cannot be faked without stealing its private key.