[Freeciv-Dev] New authentification code

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

  I'm currently working on an major overhaul of Freeciv's user-login and
authentication code.  Before you get worried about the scope, I am keeping
backwards-compatiblity modes in (for now >=) )

  The new system works by introducing two new packets and several steps in
the connection process.  It supports multiple authentication types, even
within a single game (player A can be unauthenticated, while player B has
magic cookies and player C uses a cryptographic signature), deals fairly well
with combinations of capabilities (in the example above, A's client may not
support authentication at all, and B's may not have the crypto patches from
the hypothetical site non-us.freeciv.org), and is (hopefully) easy to extend
for new authentication types.  Currently the structure is written and I'm
trying to determine the best way, or whether, to tweak the routines in
civserver.c (eg, handle_join_game_reply and accept_new_player) to deal with
the new code.

  Here's how it works, someone please tell me now if I did something colossally
stupid!

  When the client first connects, it sends a join_game packet as usual and
receives a join_game reply.  However, the reply (if the client has the
+AUTHENTICATION capability) has a meaningless value of you_can_join; instead,
a list of (string names of) available authentication methods is included at the
end of the message.  (I could create a new packet type which leaves out the
you_can_join, and maybe message, fields, just for +AUTHENTICATION clients;
is this worth it?)

  This is where things get interesting.  There is a new packet type,
struct packet_auth_message, which contains two bits of information:
 (a) A name of an authentication mechanism
 (b) Up to 512 (could be increased if needed) bytes of arbitrary information
    in network byte order.  (this is a variable-length field, since it might
    be desirable to send anything from 0 to 512 bytes of data)

  This is used to complete the connection.  The client indicates which
authentication mode it wants by sending a packet with that mode indicated in
the 'name' field.  What else is included depends on the method used; for
example, some methods will require a password, while others may require the
packet to contain no data (the method that mimicks the old Freeciv behavior
will do this, as will anything that needs the server to send a challenge first)

  If the server desires, it can reply by sending the same packet type; the
client can reply with another auth_message packet, and so on.  When
authentication completes, the server sends the other new packet type,
struct packet_auth_result, which indicates acceptance or rejection of the
authentication information and a message (similar to the join_game_reply
packets)

  Legacy clients will be handled by forcing them to use the historical
authentication method if it is enabled, or rejecting them if it is disallowed
by the server operator.

  Internally, this is implemented slightly differently from the rest of Freeciv,
which I hope is acceptable; basically I have a table of type structures, each
of which contains a bunch of function pointers.  (the reason that I didn't go
in for huge switch statements is that this will make it easier to add auth
types..hopefully..and I just find it to be more readable)

  This is all leading up to one question:
    Should I check for collisions with the names of existing players before
   or after the authentication phase?  The existing code might be slightly
   easier to integrate if I choose 'before', rejecting players who trigger
   name clashes without the authentication phase, but some people claim that
   this is a security hazard.  (OTOH, it's probably not that much easier;
   most of handle_request_join_game will have to be rewritten or at least
   altered anyway)

   Thanks,
  Daniel

-- 
Who is General Failure, and why is he reading my hard drive?