Research branch for a STARTGSS option.

Just like STARTTLS is used to initiate TLS over a plaintext
connection, could STARTGSS be an alternative based on a
GSS-API mechanism for securing connections.

Formally, GSS-API is not a protocol but a manner of securely
wrapping binary frames.  Their transport is another matter,
except in practice.

A common protocol format carrying GSS-API is to prefix its
frames with a 32-bit length in network byte order.  Slightly
more daring, and only possible for some transports, is to
rely on the carried message to indicate its boundaries.  That
would (probably) work with the Kerberos5 mechanism, but it
gets ugly fairly quickly.  Still, this is a doable variation
to support, and thus turn GSS-API into a trivial protocol.

The foregoing assumes TCP, for its strength (reliable
transmission) but also its weakness (no indication of
frame boundaries).  Other options exist too.

GSS-API over UDP would involve resends.  We should not get
too thrilled about that, except that it might allow us to
carry an existing transport from one endpoint to another,
while retaining the solid reliability of the session.

GSS-API over SCTP makes a lot more sense already.  This
protocol has reliable delivery, may send out-of-order (and
that is also an option in GSS-API, I seem to remember)
and it can be serviced over alternative paths, even some
over IPv6 and others still over IPv4.

Finally, AMQP 1.0 might be an option to consider.  We use
it for our shells in precisely this combination.  Frames in
AMQP 1.0 are more loosely connected than in SCTP, but they
can reference another to which they form a reply, thus
creating a session concept quite easily.

With the exception of AMQP 1.0 these protocols are built
into operation systems.  This means that supporting them
in this novel scheme should be possible, and make GSS-API
into an interesting design challenge for the TLS Pool.