mechglue SPI to mechanisms

Sam Hartman hartmans at MIT.EDU
Tue Dec 23 13:38:20 EST 2008


>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Tue, Dec 23, 2008 at 11:40:37AM -0600, Nicolas
    Nicolas> Williams wrote:
    >> On Tue, Dec 23, 2008 at 07:06:26PM +1100, Luke Howard wrote: >
    >> Another approach would be GSS_Query_context_attr(), as defined
    >> in > NegoEx. But that seems a bit SSPI-ish.
    >> 
    >> I don't mind.

    Nicolas> I spoke too soon: I prefer interfaces that use OIDs
    Nicolas> (though, of course, these should be hidden from the
    Nicolas> developer, in that symbolic names should be provided for
    Nicolas> all OIDs known to the mechglue and for all OIDs known to
    Nicolas> each mechanism).
So, I'm not sure how extensive of a project discussion is needed here.
I seem to recall a fairly extensive discussion of this issue years ago.

I don't think I have a lot more time to write this up than to slap a
copy of gssapi_ext.h into a project and to make sure that everything
there is actually implemented.

This shouldn't stopp you from raising objections, of course, just be
aware that this is in many ways very much a side project along-side
the real work Luke has been working on. It actually gives us a
shipping mechglue layer.  I think that's really neat, but it doesn't
create more hours in the day for a long debate.  so, let's have the
objections we need to have (if any), but focus on rapid closure and on
ways to meet objections that involve minimal code change where
possible.

I have a couple of write-ups ahead in the queue , so you may want to
get a head start by looking at src/lib/gssapi/generic/gssapi_ext.h on
the mskrb-integ branch.

We already have the session key APIs as an open issue  and we've
already discussed the IOV stuff in significant detail.




More information about the krbdev mailing list