problems with gss_accept_sec_context in 1.2.5

[Darren Reed (Optimation)]

Grumble.  This problem ended up being a result of me not quit groking
properly code I'd written 6 years ago and didn't document very well how
the damn thing worked (lesson learnt!).  Further research revealed that
we were sending the AS-REQ directly to the KDC(s) and that we were
sending the AP-REQ through gss_init_sec_context().

----- Original Message ----- 
From: <Nicolas.Williams at ubsw.com>
To: <darrenr at optimation.com.au>
Cc: <krbdev at mit.edu>
Sent: Saturday, August 24, 2002 12:09 AM
Subject: RE: problems with gss_accept_sec_context in 1.2.5


> 
> GSS-API is a generic API for network authentication. As such it does
> not concern itself with the mechanics of how credentials are obtained
> so much as with the mechanics of how network authentication is
> performed (namely, by exchanging opaque tokens).
> 
> Therefore the GSS-API KerberosV mechanism only concerns itself with
> the AP exchange, and gss_init_sec_context()/gss_accept_sec_context()
> only produce AP-REQ and AP-REP messages, respectively. But see RFC1964.
> 
> Of course, a GSS KerberosV mech implementation will take care of doing
> TGS exchanges for fetching service tickets as needed. But this is
> transparent to the application and no TGS message tokens are produced
> or consumed by the gss_init/accept_sec_context() functions.
> 
> Cheers,
> 
> Nico
> -- 
> 
> > -----Original Message-----
> > From: darrenr at optimation.com.au [mailto:darrenr at optimation.com.au]
> > Sent: Friday, August 23, 2002 4:25 AM
> > To: hartmans at mit.edu
> > Cc: darrenr at optimation.com.au; krbdev at mit.edu
> > Subject: Re: problems with gss_accept_sec_context in 1.2.5
> > 
> > 
> > From: Sam Hartman <hartmans at mit.edu>
> > > >>>>> "darrenr" == darrenr  <darrenr at optimation.com.au> writes:
> > > 
> > >     darrenr> I'm in the process of porting a home-grown Kerberos
> > >     darrenr> application that uses the GSSAPI and its own 
> > TGT.  Ok so
> > >     darrenr> far.  The problem is that we have been passing the TGT
> > >     darrenr> into gss_accept_sec_context (using another vendor's
> > >     darrenr> Kerberos) and this no longer works.
> > >     darrenr> gss_accept_sec_context only appears to handle 
> > AP_REQ's -
> > >     darrenr> not AS_REQ's or TGS_REQ's.  See:
> > > 
> > > What would it mean for GSSAPI to handle as_req or tgs_req?  You need
> > > an ap_req to start the GSSAPI exchange.
> > 
> > So you're saying the GSSAPI was not designed for it to be used in
> > obtaining an as_rep or tgs_rep ?
> > 
> > In the past, we've passed an as_req as the input token and received
> > an as_rep as an output token.  I do admit I have no idea of what
> > is actually happening under the covers in this particular library
> > implementation (yet).
> > 
> > Our code looks something like this:
> > 
> > major = gss_accept_sec_context(&minor, &context, creds, &inToken,
> >                                GSS_C_NO_CHANNEL_BINDINGS,
> >                                &cp->fl_src, &mech, &outToken
> >                                &rFlag, &rTime, &delay);
> > 
> > Where "inToken" contains an AS_REQ - something similar to what
> > you see on the wire, coming out of kinit.
> > 
> > I'll go checkup the RFC for the GSSAPI, but if we're doing that
> > and that's not meant to be possible/outside of the scope of the
> > GSSAPI, then that's good to know too.
> > 
> > Darren
> > 
> > _______________________________________________
> > krbdev mailing list             krbdev at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/krbdev
> > 
> 
> Visit our website at http://www.ubswarburg.com
> 
> This message contains confidential information and is intended only 
> for the individual named.  If you are not the named addressee you 
> should not disseminate, distribute or copy this e-mail.  Please 
> notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system.
> 
> E-mail transmission cannot be guaranteed to be secure or error-free 
> as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses.  The sender therefore 
> does not accept liability for any errors or omissions in the contents 
> of this message which arise as a result of e-mail transmission.  If 
> verification is required please request a hard-copy version.  This 
> message is provided for informational purposes and should not be 
> construed as a solicitation or offer to buy or sell any securities or 
> related financial instruments.
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev
> 
>