problems with gss_accept_sec_context in 1.2.5

[Nicolas.Williams@ubsw.com]

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.