Sergio.Gelato at astro.su.se
Tue Feb 20 11:02:49 MST 2007
* Åke Sandgren [2007-02-17 09:36:07 +0100]:
> On Fri, 2007-02-16 at 23:36 +0100, Sergio Gelato wrote:
> > My main gripe so far is that the implementation doesn't apply any
> > message integrity checks to the client-server connection. I don't
> > think it would be a good idea to release a version without MIC support.
> Yes, this is also our main problem with this.
> To get this into shape one would perhaps have to rewrite the server-mom
> communication interface altogether.
> I would also like to see client-server authentication and of course
We can start by looking at the wire protocol. As it currently stands,
the GSSAPI code only sends/receives context establishment tokens
(type TOKEN_CONTEXT in pbsgss.h). At the moment, the tokens aren't
sent in DIS format but as purely binary data (a single octet for
token type+flags, then a 4-octet token length in network byte order,
then the token itself). All bits in the type+flags octet already
have names in pbsgss.h, so one wonders what will happen if one
later needs to add more flags. (Sending the type+flags as a DIS integer
would eliminate this concern.) The type+flags octet is suppressed if it's
zero; this looks like an unnecessary complication (especially since it
can't actually happen in the current code), let's get rid of it.
To add message integrity checks, the easiest may be to call
gss_wrap() from within (*disw_commit)(), send the resulting token over
the wire, and have (*dis_gets)() and friends call gss_unwrap()
I've just been studying RPP. It looks like one should be able to call
gss_wrap() from within rpp_form_pkt(), and gss_unwrap() from within
rpp_recv_pkt(). Authentication will start with an RPP_HELLO1 message
which could be extended to contain the initial token from
gss_init_security_context(). One probably needs a new internal state,
call it RPP_GSS_INIT, and a new message type (RPP_GSS_TOKEN). And
of course the security context should be saved in the stream structure.
Packets will have to be somewhat smaller that RPP_PKT_DATA before
wrapping; call gss_wrap_size_limit() to find out the new maximum size
(it's mechanism-specific, so the value may differ from stream to stream).
The streamid is needed in order to locate the security context for
unwrapping, so the packet header shouldn't be wrapped. (Someone might
want to turn on the confidentiality flag.) The MIC makes the CRC redundant.
This actually looks cleaner than the TCP implementation. I particularly
dislike that retry loop in pbsgss_server_establish_context() when getting
the next token from the remote end; as well as the statement that
pbsgss_recv_token() "blocks to read the length and data, if necessary".
Maybe it would be better to send each continuation token in its own
request, so that other connections can be serviced in the meantime.
Does this make sense? Am I overlooking something obvious (or maybe not
More information about the torquedev