[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject

  4.1.  Initial steps
     (I) invokes GSS_Init_sec_context() with :
       major_status = GSS_S_CONTINUE_NEEDED
       output_token = negTokenInit
  4.2  Successful negotiation steps
     (T) receives the negotiation token (negTokenInit) from (I)
     (T) invokes GSS_Accept_sec_context() with :
          input_token = negTokenInit
          output_token = negTokenTarg

I think the "correct" behavior would be to do gss_init_sec_context to
get the mechList (provided you could somehow suppress the mechToken)
and then just discard the half-baked security context. Now the client
sends a NegTokenInit which is used with gss_accept_sec_context.

The client must do the same sort of thing calling gss_accept_sec_context
and then start over calling gss_init_sec_context. Consider the SMB
extended security exchange:

  SMBCMD                      CLIENT          SERVER
  NEGOTIATE                                ->
  NEGOTIATE Response                       <- NegTokenInit
  SESSION_SETUP_ANDX          NegTokenInit ->
  SESSION_SETUP_ANDX Response              <- NegTokenTarg

So the NEGOTIATE Response and the SESSION_SETUP_ANDX *both* send
NegTokenInit tokens. So maybe the server is switching roles from initiator
to acceptor and visa versa for the client.

3) This one's a little CIFS specific but the
spnego/accept_sec_context.c:send_supported_mechs function sends
the quark$@FOO.NET style name in negHints but I see Samba returns
cifs/quark.foo.net@FOO.NET. What is the difference between these service
principal types? Is the first NetBIOS based (port 139 only) and the
other DNS based (port 445 only)?

4) In gss_spnego_accept_sec_context if src_name != NULL it is set to
GSS_C_NO_NAME. It is not examined again until the end of the function:

    if (ret == GSS_S_COMPLETE) {
        if (src_name != NULL) {
            ret2 = gss_duplicate_name(minor_status,

This fails with GSS_S_BAD_NAME because of mechglue/g_dup_name.c:

    if (input_name == 0)
        return GSS_S_BAD_NAME;

First, if gss_duplicate_name is given GSS_C_NO_NAME, should it simply
set output_name to GSS_C_NO_NAME and return GSS_S_COMPLETE? If so,
then gss_release_name will also need to ignore GSS_C_NO_NAME and simply

Second, I think the condition above should either be removed (in
conjunction with gss_{duplicate,release}_name changes) or it should
simply be changed to something like:

    if (src_name != NULL && ctx->mech_src_name) {

The ultimate goal here is that I think it should be possible to specify
a src_name parameter even if ctx->mech_src_name is NULL because there
is no mech_input_token.

5) # make install-exec does not install all libraries libraries. Meaning
if one makes changes to the spnego code it will not be installed. I have
since discovered that make install in the lib/spnego directory does the
trick which is much easier for me! But still ...

6) SPNEGO fails because of the below code
mechglue/g_init_sec_context.c:gss_init_sec_context. The target_name
(union_name below) has a name_type of GSS_C_NT_HOSTBASED_SERVICE which,
if we follow the below logic, does not match GSS_C_NO_OID or the mech_type
and therefore fails with GSS_S_BAD_MECH. I'm not certain I understand why
"it must match the mech_type that we're about to use". If you negate the
conditional expression with a if (0 && as I have done, the code works

     * If target_name is mechanism_specific, then it must match the
     * mech_type that we're about to use.  Otherwise, do an import on
     * the external_name form of the target name.
    if (union_name != NULL) { 
        if (0 && union_name->mech_type != GSS_C_NO_OID) {
            if (!gss_oid_equal(union_name->mech_type, mech_type))
                return GSS_S_BAD_MECH;
            internal_name = union_name->mech_name;
        } else {
            status = __gss_import_internal_name(&minor,
            if (status != GSS_S_COMPLETE)
                return GSS_S_BAD_NAME;
    } else {
        internal_name = GSS_C_NO_NAME;

7) Should I copy the MIT list with mechglue issues? Where is mechglue's

8) What's the plan for the mechglue-branch? I'm just wondering what
parts deserve attention and what parts are maintained elsewhere.

9) My build notes have evolved to include a few extra little steps. Steps
that might need to be factored in when mechglue is merged?

$ vi cf/Makefile.am.common
  and add 'INCLUDES = ' at top to suppress error messages:
  lib/gssapi/Makefile.am:5: INCLUDES must be set with `=' before using `+='
  lib/mechglue/Makefile.am:5: INCLUDES must be set with `=' before using `+='
  lib/spnego/Makefile.am:5: INCLUDES must be set with `=' before using `+='
$ ln -s /usr/share/libtool/ltmain.sh ltmain.sh
$ aclocal -I cf
$ autoconf
[what exactly does 'autoreconf -fi' do?]
$ autoheader
$ automake --add-missing
configure.in: installing `./install-sh'
configure.in: installing `./missing'
appl/dceutils/Makefile.am: installing `./compile'
configure.in: installing `./ylwrap'
configure.in:21: installing `./config.guess'
configure.in:21: installing `./config.sub
$ ./configure --enable-shared
<snip lots of output>
config.status: creating appl/dceutils/Makefile
config.status: creating doc/Makefile
config.status: creating tools/Makefile
config.status: creating include/config.h
creating include/version.h
$ vi kdc/kstash.c
  %s/des_random/des_random0/g to resolve symbol conflict with symbol in des.h
$ make
# make install
# cp mech.conf /etc