[19265] in Kerberos
GSS context negotiation oddity
daemon@ATHENA.MIT.EDU (Larry Tremblay)
Sat May 17 19:09:19 2003
From: "Larry Tremblay" <lrt512@rogers.com>
To: <kerberos@mit.edu>
Date: Sat, 17 May 2003 19:08:02 -0400
Message-ID: <001301c31cc9$2a8a8070$8c00a8c0@larry>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
