Subject: Re: Working Group Last Call: Stackable Generic Security Service

From: Martin Rex <[email-masked]>
Date: Tue, 7 Nov 2006 20:07:13 +0100 (MET)

Nicolas Williams wrote:
> 
> > Two observations:
> >  - A lot of existing gss-api mechanism do not return a mechanism OID
>                                         ^
> 					implementations, right?

Right.

> 
> Unless the header on the initial context token is corrupted there is
> always an OID available.
> 
> >    from failing (initial) gss_init_sec_context() and gss_accept_sec_context()
> >    while at the same time they return a mechanism-specific minor_status.
> >    This may create a difficulty for gss_display_status(minor_status)
> >    to identify the particular gssapi mechanims that created this
> >    minor status.
> 
> We have this difficulty now with SPNEGO.

I think an explicit mentioning of the issue and the shortcoming in
many existing implementations might help to improve the situation
in the future.

> 
> >  - The reason for CAT to drop gss_release_oid() and friends from
> >    the v2 spec was the incompatibilities between different
> >    heap (m)allocators, and the resulting problem for gss_release_oid()
> >    to distinguish (originally purely-static) OIDs from dynamic ones
> >    created by the gssapi mechanism.  On Windows and OS/2, each DLL
> >    may use its own/seperate instance of a heap (m)allocater, and
> >    considering the explosion of incompaible MSVCRT.DLLs (VS.NET 2003/2005)
> >    using the WinSxS scheme, this is actually the norm today for software
> >    that meets in the field (and is not produced in a single compile).
> 
> Ah, but the same problem exists with gss_release_buffer().

Nope, it doesn't apply to gss_release_buffer.

All >>output<< parameters of type gss_buffer_t are dynamically allocated
by the gssapi mechanism and must be passed to gss_release_buffer().

Except for gss_release_buffer(), >>input<< gss_buffer_t parameters
are to be considered read-only by a gssapi mechanism implementation.
(Nit-picking: the gss_buffer_desc structure is always owned by the
 application caller, only the contents of gss_buffer_t output parameters
 are dynamically allocated and therefore owned by the gssapi mechanism).

The difference with dynamic OIDs is, that there are several existing
gssapi calls that provide gss_OID output parameters, but all of them
are read-only/static (because there was no gss_release_oid() in
GSS-API v1, and there is none in GSS-API v2u1).

You're now about to create gss-api calls that create dynamically
allocated OIDs, and that is a significant change in semantics,
so it deserves an explicit warning label.

The textual description of gss_release_oid() in the GSS-API cbindings
draft at the time when rfc2078.txt was published was extremely dangerous.

> 
> > I'm not sure who might be the real target audience for the
> > stackable GSS Mech spec.  IMHO, it's not the portable applications
> > writer that call gss-api v2.
> 
> The same might apply to SPNEGO.

No, not really.  SPNEGO was designed so that the portable application
callers should be able to transparently benefit from it.  SPNEGO
doesn't need any additional API calls, and the more "portable"
the application, the more likely simple client components will
"just work", indepent on what mechanism(s) the administrator
installs.

> 
> > require a gss-api (multi-)mechanism that used these extensions
> > to provide the benefit in a gss-api v2 transparent fashion?
> 
> No, it wouldn't.  The extended mech inquiry functions are there to make
> it possible to safely construct composite mechanisms; without these the
> composite mechanisms can only be pre-configured.

I meant a (gssapi mechanism of the composite type, i.e. one combines
existing gssapi mechanisms, but looks like a seperate gssapi mechanism
to a portable application.

As you might have noticed, there is a real problem with resource
management (gss_buffer_t and gss_OID_set) when trying to build
a multi-mechanism on top of several existing gss-api mechanisms
or a single- or multi-mechanism of the composite type, because
you either need to memorize where dynamically allocated
gss_OID_set and gss_buffer_t originated, or you need to
blindly copy them on output and have the top layer become
the owner / resource manager and avoid the problem of not
knowing what to do if gss_release_oid_set or gss_release_buffer
is called.

For message protection, this results in extra copying of data.

When not using a "standardized" API and building a monolithic
multi-mechanism, one can optimize by either using the same
heap (m)allocator, or by always having the top layer allocate
the return buffer and provide them to the lower layers.
Therefore a kind of callback like gss_alloc_buffer(), offered
by the intermediate "multi-mech or composite-mech glue"
and called by the lower-layer gssapi mechanism might reduce
the amount of copying.

-Martin

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