Roles: (They are all standard names for this kind of thing but why not)

Alice (The end user / the minecraft client software)
Bob (The Minecraft Server the user wants to connect to)
Trent (The Minecraft.net Server)
Eve (The hacker who is trying to impersonate Alice and connect to Bob)
Before anything happens, Alice generates an RSA Keypair and both Alice and Bob get a verified copy of Trent's public key wrapped in a certificate with full chain of trust signatures resolved which is also fully valid for login.minecraft.net.
Alice's public key will be known as APK.
Trent's public key will be known as TPK.
This proposition includes alternate verification. Standard login is known as protocol 14A. The optional extension is known as 14B. 14B can only be used if 14A has been used recently (Specifically if APK's hash is still present and valid in Alice's revokation list)


// LOGIN PROTOCOL 14A
First, Alice generates a random nonce known as ARN. She then encrypts her Password using this Nonce as the key, the result of which is known as AEP. Then, she encrypts the Nonce and the encrypted password using TPK. This result is known as TEP.
Alice connects to Trent (The connection from earlier can be reused if it's still valid).
    Alice sends Trent her Username, TEP, and her Public key and that she's logging in using protocol 14A.
        Trent now begins decrypting TEP.
            He decrypts TEP using his Private key, and gets ARN and AEP.
            Then, using ARN as the key, he decrypts AEP to get Alice's password.
            Then, he checks to make sure Alice's password is correct.
            Now that Alice has verified, he generates a login certificate containing APK, Alice's username, and a timeframe for which the certificate is valid and signs it.
            The signed Login Certificate for Alice is now known as ALC.
            /* The following is only used if Trent wishes to implement Protocol 14B.
            He also stores a hash of APK in Alice's revokation list.
                If this hash is already there, it simply updates the last used time.
                Note that if a hash is not used in a timespan is CAN be removed from Alice's revokation list.
                Also note that Trent can limit the number of hashes per user.
            */
    Trent then gives Alice ALC encrypted with Alice's public key. // Fixes replay attacks
    Alice decrypts ALC with her Private key, and then verifies it has her public key and Username, and verifies the signature using TPK.
    Alice Disconnects.

At this point, the following is true.
APK: Public
TPK: Public (Verified)
ALC: Public (Signed) (Verified)
ARN: Secure
AEP: Secure
TEP: Public (Encrypted with TPK)
Alice's Username: Public (Verified)
Alice's Password: Secure (Verified)


// LOGIN PROTOCOL 14B
Alice requires a signed and verified copy of ALC AND the matching private key for this protocol. If she does not have it, she has to fallback to protocol 14A. This signed copy of ALC and Alice's private key should only be saved to disk if the user specifically selects Save Login Credentials.
Alice connects to Trent and sends Trent ALC and that she's logging in using protocol 14B.
    Trent verifies that ALC is valid.
    He then generates a hash of APK and checks it versus Alice's revokation list.
        If it is not there, authentication fails.
        If timeouts are required, and it's out of date, Authentication fails.
		If authentication has failed, Trent tells Alice that it has failed with the reason, informing her to fall back to Login Protocol 14A. // No reason to sign this: If the message is altered it's still not going to return a properly updated ALC.
    If the hash is there and valid Trent updates the signature on ALC as well as updating the Valid timeframe.
    The updated ALC is then encrypted using the contained APK and sent to Alice.
    Alice decrypts her new copy of ALC and has authenticated sucessfully.

At this point, the following is true.
APK: Public
TPK: Public (Verified)
ALC: Public (Signed) (Verified)
Alice's Username: Public (Verified)
Alice's Password: Secure (Verified via ALC)


// NOTES WITH PROTOCOL 14B
If Alice changes her Password using the Minecraft.net website, ALL SAVED HASHES IN HER REVOCATION LIST SHOULD BE REMOVED.
The Minecraft.net website should also support viewing and removing hashes in the revocation list. This should include the IPs that last used those hashes (Both Alice's and Bob's), and when they were last used, so that in case a copy of a copy of ALC and Alice's Private key was aquired without Alice knowing, she can disable usage of it when she finds out.

// SERVER CONNECTION
Alice now wishes to connect to Bob.
    Alice connects to Bob and sends Bob ALC.
        Bob verifies ALC's signature using TPK, as well as verifying that the Timeframe is valid.
		/* The following is only used if Trent wishes to implement Protocol 14B.
			Bob then generates a hash of APK. He then encrypts this hash, Alice's Username, and Alice's IP using TPK. This result is known as BRR.
			Bob attempts to contact Trent, sending BRR.
				If Bob is unable to connect to Trent, authentication resumes, but Bob should log BRR for later, and should routinely contact Trent to attempt to verify BRR until it is verified sucessfully. If BRR is found to be revoked later, the server should drop Alice and possibly roll back changes to access lists.
				Trent decrypts BRR.
				Trent then compares the hash against Alice's Revokation list.
				If the hash is not there, Trent tells Bob to refuse the connection saying that ALC has been revoked. This message should be signed, and verified with TPK by Bob upon receipt.
				Trent responds to Bob saying to allow the connection, and that is has been verified as valid. This message should be signed, and verified with TPK by Bob upon receipt.
				Trent now adds a log to the hash saying Alice's IP address (from BRR) and Bob's IP address, as well as the time. This information should be available on the revokation website as per Notation for Protocol 14B.
				Trent also sends Alice's and Bob's IP to the stats server for tracking purposes.
        */
		Then, he generates a random key known as CSK and encrypts it with APK, which is known as ESK.
        Bob then sends Alice ESK.
    Alice decrypts ESK using her Private key to get CSK.
    From this point on, all traffic is encrypted with CSK using a Stream cipher. Packets can optionally include a MAC if that type of packet is flagged as security critical, such as Chat packets. If a packet if flagged as security critical and the mac is not there or not valid that packet is dropped entirely OR Alice is disconnected from the server.

At this point, the following is true:
APK: Public
TPK: Public (Verified)
ALC: Public (Signed) (Verified)
CSK: Secure
ESK: Public (Encrypted with APK)
Alice's Username: Public (Part of ALC) (Verified)
Alice's Password: Secure (Not transferred) (Verified via ALC)