[michaels@inet.no: Re: gss_accept_sec_context() problem]

[Michael Shuldman <michaels@inet.no>]

Well, I still need this to work.  Should I pursue other routes or
does someone know/is looking at what is wrong here?

Please Cc: me on any reply.

----- Forwarded message from Michael Shuldman <michaels@inet.no> -----
Message-ID: <20000731105428.37476@bastesen.inet.no>
Date: Mon, 31 Jul 2000 10:54:28 +0200
From: Michael Shuldman <michaels@inet.no>
To: Assar Westerlund <assar@sics.se>
Cc: heimdal-discuss@sics.se
Subject: Re: gss_accept_sec_context() problem
References: <20000728144948.14080@bastesen.inet.no> <5lzon1fq14.fsf@assaris.sics.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <5lzon1fq14.fsf@assaris.sics.se>; from Assar Westerlund on Sat, Jul 29, 2000 at 07:45:27AM +0200
Status: RO
Content-Length: 2139
Lines: 50

Assar Westerlund wrote,
> Michael Shuldman <michaels@inet.no> writes:
> > I can't see any requirement for input_token to be filled when calling
> > gss_accept_sec_context() and was expecting GSS_S_CONTINUE_NEEDED.
> 
> I don't think it makes much sense to call gss_accept_sec_context with
> an empty token.  What would it mean and why would you do it?
> 
> GSS_S_CONTINUE_NEEDED is used when authentication requires more steps,
> to indicate that you should continue looping around
> gss_accept_sec_context (and gss_init_sec_context).
>
> I changed the code to return GSS_S_DEFECTIVE_TOKEN instead of crashing.

The draft (cbind-09) says that GSS_S_CONTINUE_NEEDED "Indicates
that a token from the peer application is required to complete the
context ...".  Isn't that the case here, "a token from the peer
application is required"?

> > I tried filling input_token with the token gotten on the clientside
> > from gss_init_sec_context, a assert() in Heimdal then fails.  I
> > guess I'm doing something wrong here?
> 
> Can also possible be us doing something wrong. :-)  Just send us the
> assert that's failing and we will look at it.

Here it is (I didn't include it in the prevous mail since I'd deleted
the coredump, will try not to do that so soon now):

#0  0x94f9f in kill ()
#1  0x949e4 in abort ()
#2  0x2c6c1 in gssapi_krb5_verify_header (str=0xdfbeaef0, total_len=1026, 
    type=0x2c172 "\001") at decapsulate.c:51
#3  0x2c7c3 in gssapi_krb5_decapsulate (input_token_buffer=0xdfbfb0a0, 
    out_data=0xdfbeaf34, type=0x2c172 "\001") at decapsulate.c:90
#4  0x2c2ab in gss_accept_sec_context (minor_status=0xdfbfb0cc, 
    context_handle=0xdfbfb0a8, acceptor_cred_handle=0x0, 
    input_token_buffer=0xdfbfb0a0, input_chan_bindings=0x0, 
    src_name=0xdfbfb0bc, mech_type=0x0, output_token=0xdfbfb098, 
    ret_flags=0x0, time_rec=0x0, delegated_cred_handle=0x0)
    at accept_sec_context.c:118

The arguments to gss_accept_sec_context() should be the same as in
the testprogram except for input_token, which is the token the
client got from gss_init_sec_context().

-- 
  _ // 
  \X/ -- Michael Shuldman <michaels@inet.no>

----- End forwarded message -----

-- 
  _ // 
  \X/ -- Michael Shuldman <michaels@inet.no>