GSS context negotiation oddity

[Larry Tremblay]

I have client and server applications that are trying to negotiate a
GSSAPI context using Kerberos as the GSS provider.  My setup:

- Server running on Redhat Linux 9, using Kerberos 1.2.8 as the KDC
- Client running under Windows 2000, using Kerberos for Windows 2.1.2
libraries

Now then...

The server starts up and acquires server credentials via
gss_acquire_cred, using GSS_C_ACCEPT and a name that has been imported
using gss_nt_service_name. 

The client starts up and calls gss_init_sec_context, and is given a
token and GSS_S_CONTINUE_NEEDED as the major status; the client passes
the token to the server.

The server receives the token and uses it to call
gss_accept_sec_context, and is given a token and GSS_S_COMPLETE as the
major status; the server passes the token to the client.

The client receives the token and uses it to call gss_init_sec_context
again, and is given a null token and GSS_S_COMPLETE as the major status.

(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.)

At this point,  if the client uses the context handle returned from
gss_init_sec_context, I am returned GSS_S_NO_CONTEXT from gss_get_mic.
Likewise, the context handle that the server got on its call to
gss_accept_sec_context yields only GSS_S_NO_CONTEXT from gss_get_mic.

Any ideas as to why:
1) The server is getting GSS_S_COMPLETE on its first call to
gss_accept_context?
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?

It's almost like the client is wanting a double exchange negotiation,
but the server is only doing a single exchange negotiation.  I hope this
is something really simple that I'm missing.

Thanks,
Larry