GSS context negotiation oddity

[Ben Cox]

On Sat, 2003-05-17 at 19:08, Larry Tremblay wrote:
> (If I pass that null token to the server and try to pass it to
> gss_accept_sec_context, I get a GSS_S_FAILURE as them major status, with
> a minor status indicating a defective token - as one would expect since
> the initial call to gss_accept_sec_context returned GSS_S_COMPLETE.)
[...]
> Any ideas as to why:
> 1) The server is getting GSS_S_COMPLETE on its first call to
> gss_accept_context?

Yes; the server only needs to look at the client's token once to
authenticate the client.  You need two calls at the client because at
the time of the first one you haven't received a token from the server
yet (so the tasks of creating your token and validating your peer's
token must be split into two calls).

Your first call at the client prepares the client's token.  The (single)
call at the server validates the client's token and prepares the
server's response.  The second call at the client validates the server's
response (mutual authentication).

(If you don't use the mutual authentication flag, you will get a
GSS_S_COMPLETE after the first call at the client too, IIRC.)

> 2) Why the second call of gss_init_sec_context is not giving a token to
> return to the server - even if it isn't expecting one?

Because there's no need for one, given the above exchange.

Note the following text from RFC 2744 (section 5.19):

   The routine may return a output_token which should be transferred to
   the peer application, where the peer application will present it to
   gss_accept_sec_context.  If no token need be sent, 
   gss_init_sec_context will indicate this by setting the length field
   of the output_token argument to zero. To complete the context
   establishment, one or more reply tokens may be required from the peer
   application; if so, gss_init_sec_context will return a status
   containing the supplementary information bit GSS_S_CONTINUE_NEEDED.
   In this case, gss_init_sec_context should be called again when the
   reply token is received from the peer application, passing the reply
   token to gss_init_sec_context via the input_token parameters.

It then goes on to say that you should use the token length along with
the return status to figure out whether you need to send a token or not,
and gives pseudocode that shows the correct behavior.

So, basically: don't try to send that null token to the server.  The
null token that you get back from gss_init_sec_context is just the
GSS-API way of telling you that you can stop passing tokens now.


-- 
Ben Cox <cox-work at djehuti.com>