JeffJournal

Spent the remainder of the day hacking minime socket classes (partially as a result of jjc -- because it wants to use no authentication and no encryption to connect up to the web server --
but it was due to happen anyway; better sooner than later). Had to make the authentication and encryption be "mo' separate" than they originally were. This actually led to the sockets being able to accept multiple kinds of encryption and/or authentication in an IMPI kind of way (amazing how this Ph.D. thing really ties in all work that you have previously done...). Also inspired by ssh. It goes like this...

Sidenote: This is lengthy not just because I'm telling people what I'm doing, it's lengthy so that I myself have a record of what I'm doing. Will be quite helpful when I actually go to write that dissertation! Also, I'm about to effectively go on vacation for about 1.5 weeks, and my short term... what was I talking about?

Assumptions:

• Authentication is a different step than encryption. First you authenticate, then you setup encryption. A successful connection must pass both steps on both sides.

• Connector and acceptor potentially have different lists of authentication/encryption methodologies. Each entity has a list of auth/enc methods that it will allow -- these lists are in priority order. i.e., "strongest" methods are listed first.

• The acceptor governs the authentication/encryption choice (i.e., the "server"). As a side effect of this, if the acceptor has no authentication methods defined (for example), the authentication passes (even if the connector has some authentication methods defined).

• Authentication/encryption methods are indexed by their string names (makes debugging easier, for one thing).

• Different authentication methods can allow for different levels of security. For example, a "shutdown" authentication is assumedly only given to root -- so that root is the only user who can shut down a minime daemon.
  

The overall process is just about the same for authentication as it is for encryption, so I'll just describe the authentication.

1. Connector makes a socket connection to the acceptor.

2. Acceptor spawns a thread to handle this connection and goes back to sitting on accept(). The new thread (after some internal accounting -- a phrase that will never die) sends an integer count of the number of authenication methods that it has, followed by a '\n' delimited string of the names of authentication methods that it has available (if there are more than 0 methods available).

   Connector receives this count and [potentially] the list of possible names.

3. If the count is zero, both sides rule that the authentication was successful. If (count > 0), the connector goes through the acceptor's list (in order) and finds if it has any of the same names in its list. If it does, it sends the integer index of the match back to the acceptor. If it does not, it sends back -1 and then hangs up, ruling that the authentication failed because common authentication method could not be found.

4. The acceptor receives the integer. If it is -1, it hangs up and the thread handling that connection dies (similarly, if the connector hangs up without sending the -1, the acceptor can deduce that there was no match found). Otherwise, both the acceptor and connector call the accept() and connect() methods (respectively) on the selected Authentication object (sidenote: it only makes sense to have two entry points to the Authentication -- it's much easier to have a 2-way protocol where each side knows who they are so that you can have defined challengers and responders, etc.).

5. The contents of the Authentication::accept() and Authentication::connect() are obviously protocol-dependent (since they now own the socket, they can do whatever the heck they want). Currently, these routines simply return a bool (remember, gentle reader, they were previously setup with whatever initialization/key/etc. information when they were initialized and attached to the Socket instance) indicating success or failure. The only condition that must be enforced is that accept() and connect() both return true or both return false. It would be a Bad Thing if they returned different answers, because then one party will think that it has passed authentication successfully while the other will hang up (upon which case the other party will detect this and also hang up, but it's Not the Right Thing to Do).
   

Once the authencitation process passes, we essentially repeat the procedure for setting up encryption. So there's multiple potential points of failure: agreeing on authentication, performing the authentication, agreeing on encryption, performing the encryption setup. If any of these steps fail, the whole connection fails and both sides hang up (assumedly with some nice error message saying what went wrong).

So this is the scheme. For all that text above, it's really not that complicated. Now I gotta go implement it. Code to write.

Woo hoo!(tm)