Subject: Re: Pluggable GSSAPI

From: Martin Rex <[email-masked]>
Date: Wed, 2 May 2007 11:47:48 +0200 (MEST)

Nicolas Williams wrote:
> 
> On Tue, May 01, 2007 at 03:24:19AM +0200, Martin Rex wrote:
> >
> > while the beauty of GSS-API (at least at the C-level) is that
> > you can easily get a large number of fully interoperable
> > implementations over many years.  We've been doing
> > binary plug'n'play with ~15 third-party gssapi mechanism
> > for the last 9 years.
> 
> You are reaching.  The standard is extensible, the protocol aspects of
> it not nearly as complex as the API itself, and as for the bits on the
> wire, the API itself defines very little.

That's probably why it has the word "generic" in its name.  ;-)

> 
> Also, there is no ABI for the C bindings, and that truly sucks.

NOT AT ALL.  The information in rfc-2744 C-Bindings Appendix B is perfectly
sufficient for binary plug'n'play.  We always intended to be using
GSS-API v2 with binary plug'n'play since 1996 and (aside from buggy
and broken gssapi mechanism implementations) it works like a charm.
Paired with common sense rfc-2744 Appendix A gssapi.h sample header file
and Appendix B Additional constraints for application binary portability
it is sufficiently close to an ABI for all practical purposes.

(There was one potential problem due to the reference of "xom.h"
 and the braindead binary-incompatible change of xom.h for 64-bit
 for the OID_set structure, but that problem cured itself all alone
 by xom.h and its ilks becoming extinct long ago.)

> 
> > 
> > For GSS-API, the question would be whether parallel calls
> > (in seperate threads) to message protection (=write) and
> > message unprotection (=read) on the same gssapi security context handle
> > should be supported.
> 
> RPCSEC_GSS depends on it!

But you do realize that GSS-API does NOT address multithreading at all,
so from the spec alone, one must NOT assume that concurrency is allowed
for any of the GSS-API calls.  And even gssapi mechanism that support
multi-threading in some fashion will NOT automatically allow concurrency
on the same object handles (=data structures).

If RPCSEC_GSS really _depends_ on this, it will work only with a very
small set of hand-selected GSS-API mechanisms and looking at SPNEGO
and for plug'n'play would be looking for neverending trouble.

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten