There was a recent discussion I read about here, I believe it was in one of the Aspect client threads, about MUD proxies and relaying client information to a MUD server. It led me to thinking about a simple message-digest based protocol for a proxy to communicate to a server the client information (amongst other things) and allowing the MUD server to trust that the message comes from a trusted proxy.

The basic solution is a very GMCP-like protocol that uses HMAC-based signatures (using SHA1 as the hash function) with shared secret keys unique to a (proxy, mud) pair.

This protocol introduces a new telopt named PROXY, assigned as 0xCA (decimal 202) and currently supports two GMCP-like commands, ClientInfo and Disconnect. Any command that requires a signature will have the payload prefixed with said signature, and the receiving party will use the payload plus the shared secret key to generate its own signature and compare it with the sent signature to determine validity.

The technique is inspired by modern APIs, particularly Amazon AWS. AWS and the third-party application share a secret key and a public key that the third-party application is known by. Any request that requires a signature is signed using the shared secret key, and the public key is sent along in plain text. AWS (in this case) looks up the proper secret key based on the supplied public key to generate its own signature and compare.

The draft as it stands is hosted on github and has MUCH more detail, and I encourage forks and pull requests for changes: https://github.com/avidal/mud-proxy-prot...

That does it.

Internet is over, folks, go home.

What?

LOL… Mmmmm PCP!

Take this straight to mudstandards.org for consideration.

I think the point people are trying to make is: why do we need this?

You probably don't. We do.

That's what I was thinking, but I don't lurk here often enough for it to have been fully apparent.

For a quick scenario that can hopefully explain why it's useful, imagine this:

I create a web-based MUD client that anyone can use. They go onto my site, and get a customized copy of DecafMUD, for instance. All of the people that use my client connect to your MUD through my hosted proxy, so all you know is that there are X players from the same IP address. If one or two of them are malicious, what's your recourse? You can ban the character, sure, but they'll create a new one. The only way to prevent them from using my public proxy is by banning the IP address for my proxy.

However, if your server supported this protocol, then my proxy would tell your server who is really connecting (and you could actually trust that information came from me) and you can take preventative measures against the specific IP addresses that are abusing the system, as opposed to blocking access to everyone from my proxy.

Right now there aren't a ton of situations where this will be useful, but already server administrators have had issues with people connecting through mudgamers or TMC since they all show up as one IP address. If you get a rash of abuse via TMC or mudgamers you can either take it, or ban the entire proxy. There are certainly going to be more problems just like this on the way. What I'm attempting to do is get something in place that we can all agree to, so that as these proxies pop up, MUD servers can properly handle and track who is actually connecting through them.

No need to be snarky about it, Vigud, especially if you're going to create some odd "we vs. you" conflict (who is "we" anyhow?). Any project proposal should at least provide even a brief justification for its existence – which is exactly what Avidal did.

Avidal, I can see your use case, although to be honest I'm somewhat skeptical about how often this will come up. I see the shift toward the web for sure, but the direction I see things heading in is MUDs providing their own client interfaces, as opposed to people using a centralized web client that connects out to other MUDs. Still, I'm curious to see how this proceeds…

The nice thing about this is that if the MUD server provides its own client that connects through the proxy (still required for websockets, unless you add WS support directly into your codebase), and the server/proxy support the protocol, then it would, by definition, also work for other custom proxies run by other people without any extra work done on the server admin's side.

Also, you can pretty much guarantee there will be significantly more public web clients that connect to any number of MUDs through a proxy than there will be MUDs that provide their own web client. The work required for a MUD to provide its own web client is significantly higher than supporting custom clients, and even the MUD servers that DO provide their own clients typically just embed a publicly available client on their site.

Actually, that brings up another scenario that might be more applicable:

You want to drive some additional traffic to your MUD, so you get a copy of DecafMUD with the intention of embedding it into your website with a bunch of custom CSS and pre-built aliases, etc. You still need to either serve a flash policy file, or run a proxy. Let's say you run a publicly available proxy since it's easier to setup. Well, now anyone that connects to your MUD through the client on your site still shows up as a connection from your webserver IP, and not the actual player's IP address. It's the same problem, just moved to your server instead of mine.

I wasn't answering you, David Haley, but you - people who say: "why do we need this?" If you don't know why we need this, you probably don't need it at all. We, however, do need it. And by "we" I mean:

1) People like Twisol, who provide their public MUD proxies and don't want to get them banned on MUDs. Possibly TMC and MUDGamers too.

2) MUD owners who consider public proxies valuable and don't want to ban them only because individual people use them for cheating.

3) MUD owners who want to "install" standalone MUD clients, such as DecafMUD, on their websites. As avidal said, even if you start both MUD and proxy on the same server, the problem with forwarding players' IPs still exists. In this case you could use your own format, as I currently do for my MUD, but it would have been easier to use an existing one.

This looks like a great start. I don't know a whole lot about cryptography and secure authentication and whatnot, but mimicking AWS is certainly a way to do it.

Obviously there's some enmity towards proposals and standardization. :tongue: The best way to look at MPCP is as a suggestion or an idea; it shouldn't be considered a draft standard until there's a sizable amount of support.

Anyways, on the subject of MPCP itself, I can understand sending proxy name, proxy version, and client address (clearly), but what would the purpose of proxy address be? If a proxy service has multiple machines to balance load between, it's perfectly possible for one proxy service to have multiple addresses. Saying the server MAY use the address for supplemental identification is a bit brittle, and I've argued against IP-based authentication for proxies for that reason.

Also, what is the intended use of the timestamp? I see that it's required, and that if it's too old it's a valid reason to send a Disconnect, but can you detail the reasoning/purpose?

I would also replace REVOKED and KEYNOTFOUND with a single UNAUTHORIZED response, for the same reason you say "Usename and password combination not found" on a website whether or not the username exists. The proxy/client owner can always ask the MUD admin what's going on.

(edit)

I was just thinking about this, and I saw it in the FAQ. What we should really have is a message sent in response to ClientInfo which is also signed. This at least requires an impersonator to both hijack the DNS resolution and acquire the secret key.

(edit 2)
The timestamp thing is explained at the very bottom. Kind of an annoying place to put important information. :(

Yes, that can be a problem - I know people have had the same issue with FMud for example.

But DecafMUD already supports MSDP, and presumably you'd already be using PLUGIN_ID to identify your customised version of DecafMUD…so wouldn't it be easier just to add another MSDP variable to identify the user, rather than a whole new protocol?

MSDP doesn't have any kind of security. I'm sure it's possible to do (i.e. send a SIGNATURE key with the signature), but you'd have to define how the signature is created, and how the receiver recreates it from the data given. In MPCP, you just use the whole data portion of the message.

As the communication is between the proxy and the MUD server an unencrypted password communicated either over MSDP or GMCP is equally secure. I don't think it'd be a problem for a proxy to implement both protocols, and the overhead should be fairly small if the key/value pairs are identical.

This isn't GMCP, so I'm not sure what you're talking about. It's GMCP-like, but it has an extra field besides message and data that's used to sign the message. If the signature doesn't match the data, it's discarded (presumably it was modified in-transit), and the secret key means only the two parties who know the key can sign a message.

The issue with reusing MSDP or GMCP for this is that it's either potentially destructive to the telnet stream being forwarded, or requires more processing power from the proxy itself than should be necessary. That is, of course, because it's a protocol that's expected to be used for sending data between the server and client.

If the proxy starts sending its own data on one of those, suddenly you need to be processing the data–both ways–on the proxy. Some commands would need to be forwarded, some wouldn't. And what if the proxy negotiates GMCP, and the client doesn't support it, but the server starts making assumptions about capabilities (which it shouldn't do, but it very well could if the implementation is silly) and it has a negative impact on the end-user's experience? And again, it requires more processing power. With a new protocol, you only really need to watch for IAC in the streams, and check after those for WILL/WONT/DO/DONT/SB MPCP (and please remember to properly handle IAC escaping). If you go with GMCP or MSDP, not only do you have to watch for those, you have to read sub-negotiation data, decide if it's a command you care about, and do something about it or forward it (or destroy it completely).

If you think about it there's no need for a signature, all the MUD needs is to identify the proxy's IP address, and mark it as trusted. As there's no way for a 3rd party to snoop the data a plain text password would suffice for proxies with a user accessible telnet interface.

Even when a signature would be required it's possible to nest the signature inside a data package. I don't see a need for a special protocol for this, perhaps a standard for how to handle it.

No, wrong. I'm still amazed people think this way. An IP is not a constant. One: A single proxy can have multiple machines behind it. This means potentially many IPs for one proxy. Two: The proxy might be migrated to a new datacenter, or even run behind DHCP. An IP is an inherently unreliable mode of recognition. A key can be used for security and broader identification.

Furthermore, the signature doesn't just identify the proxy, it also ensures data consistency. The data cannot be modified in-transit without modifying the signature that was generated from the data plus the secret key.


Replay attacks are actually very easy to accomplish. All you need is the data being sent to the server, and you can send that exact data from your own computer. Including a timestamp in the data (and signing it) ensures that replay attacks are infeasible.

This is a pretty well-known way to attack browser cookies, as well.


Possible, yes, but it's convoluted. You have to specify which keys are (or are not) part of the signature, the order of the keys is important (or else you may hash a different string), etc. MPCP is demonstrably simple, and so far the only concern I have with it is that many MUDs (I hear) have spotty telopt support. But then, this isn't even a very complex protocol, so I would think you could provide a code snippet for it.

Assuming the setup is as following:

[browser] <———-> [mud proxy] <———> [mud server]

How will the browser intercept data sent between the proxy and the server? No interception, no replay.