[MUD-Dev] PGP player certificates (was: collecting ideas...)

Wesley W. Terpstra terpstra at iota.dhs.org
Wed Dec 22 21:03:57 CET 1999 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Dec 1999, Rahul Sinha wrote:

> On Wed, 22 Dec 1999, Wesley W. Terpstra wrote:
> > We wanted to make this mud a sort of mud network that allows players to
> > move between systems freely and without needing to trust the new server.
> 
> but their is inherent trust issue server vs server
I've spent some time putting my thoughts into a coherent discussion below.
This is a formalization of my hand-wavy 'ring' this 'ring' that from last
message.

> > [cut discussion about player data saved as pgp signed certificates]
> this is fine, but isn't this easier via a separete server-server
> protocol
Suppose the server you grew your character on was well trusted, but the
admin shut it down. A server-server protocol won't work then.  Also,
just because a client has played on two servers and they share some
trust, there's no reason the servers can reach each other. eg: muds at a
LAN party -> bring character on disk.
I am sure there are many more such examples and reasons. The root of it
is that a character is logically bound to a user, not a server.

> unless you want tforward the actual packets,  you are going to have to
> make the user reconnect to the new server.  
Remember we have a client program and specific protocol, so this
reconnection would be transparent. Besides, why tunnel if you don't have
to? You add latency and use more resources. Further, the new server may
have different services available (on diff ports) so tunneling them all
from the original server is plainly a no go.

> So he does, enters the name of
> the old server, the name of the char, and then the new server contacts s
> the old one, the old one presents a challenge that is answered
> cryptographically (think rsa keys) by the player. (there is an assumption
> of trust among the various servers, else the propagation of data back from
> the new server to the old is ludicrous) the old server then gives the new
> the vital stats, no need for pgp, and this can also allow for encrypted
> connectiosn..
What you've described is the new server ssh'ing to the old. Yes, I could
do that, but my goal is to obviate the server-server talking. I want the
character in the hands of the user, not the server.

You keep mentioning server-server trust. I've tried to collect my thoughts
about this here in a fairly general trust framework:

- ---------------------------------------------------------------
Ring based trust (current working definition - changes welcome)
- ---------------------------------------------------------------

With every server is associated exactly one ring. 
However, rings need not be associated with a server. 

Every ring has exactly:
	- one private/public key pair
	- one ringmaster (not necessarily human).

Rings are designed to create trust information about other rings.
A server trusts exactly what the ring associated with it trusts.

The ring master holds the private key. He publicizes the public key and
purpose of his ring. 

	If it's a ring bound to a server, players will want to know what
	certificates on their character the server will accept.

	If it's a ring organization like 'ninja ring of trust' then other
	ringmasters will want to know whether they want to accept stats
	that are trusted by the 'ninja ring of trust'. 

A 'ring' R has a set of the following pairs (defined now as links):
	The public key of ring O. 
	The stats that from O that R trusts.

These links are distributed by the ringmaster after he signes them with
his private key. He distributes them widely. (see footnote 1)

When building a chain from x to y (a sequence of links building trust via
links from one server to another) the stats trusted by the chain is the
set intersection of each link's stats over all links in the chain.

A bridged stat from x to y is one for which there exists a chain from x to
y containing that stat.

Notice that the set of all bridged stats from x to y is not, in general,
equal to any of the stats in a particular chain from x to y.

- ---------------------------------------------------------------------
Footnote 1: Where are the links stored and how does a client bridge a
            stat?
- ---------------------------------------------------------------------

Where links will be stored I am uncertain of.
It should be readily available so that chains can be built and bridged
stats discovered.

If someone has ideas for how I should store links, please tell me!
Also, what algorithms are good for building chains?

My thoughts so far:
	Each ring stores all the links it has made and a route to the
		embedded rings.
	Each ring periodically queries linked rings about what bridged
		stats they have from other rings at present.
	It then rebuilds its own bridge (filtering bridged stats of
		course),

I believe this should achieve the same result as a parrallelized DFS.
Am I right in this? I also believe newsgroups propogate similarly...

However, this requires that every ring be able to talk to linked rings
directly. I had hoped to avoid that. 

Are there better methods?

- --------------------------------------------------------------------
Character certificate format
- --------------------------------------------------------------------

I still have yet to hammer out a clear enough definition of what is stored
in a certificate for characters. 
- - It has to be signed by the originating ring.
- - It has to refer to the last certificate from that ring. (so players
can't drop unwanted character changes).
- - It has to refer to the end of all certificate chains imported during the
last connect (so once you import changes from another server, they stick)
- - It has to timestamp the changes so servers can reapply changes in order. 
- - It has to record the changes - this is what I'm not sure about:

If the MUD were based completely around skills and items, this might work:
store a delta for skills and item stats for items. However, this
makes effects that set your skill to a particular value impossible. 

- ----------------------------------------------
Server end data storage
- ----------------------------------------------

And finally, what does the server store? I think it should only store a
hash of the last certificate issued. Then when you connect, the server
will know if you dropped certificates and deny you access. It also
means we have very little data to store on the server. :-) :-)

- ---

> rsa != rsaref, I think the hole was a rsaref-specific problem, but je ne
> suis pas un cryptographer
Rsaref had a bug, yes, but...
I was refering to the rsa algorithm which is not proven as hard to break
as factoring. And factoring isn't proven hard either. ;-)

- ---
E-mail: terpstra at interchange.ubc.ca        Host: iota.dhs.org
PGP key: hkp://wwwkeys.us.pgp.net/terpstra@interchange.ubc.ca
         http://www.iota.dhs.org/pgp-keys/terpstra.pgp


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Comment: Made with pgp4pine 1.71b
Charset: noconv

iQA/AwUBOGGtRaYi3MeZ5h2mEQJTswCeIZPwh76FCbvJBqQl3ZcpxCsGuP4An0yn
wgNCSYpLyLxKk9YawJNRM2Id
=TLZJ
-----END PGP SIGNATURE-----




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev

More information about the mud-dev-archive mailing list