Re: Working Group Last Call: Stackable Generic Security Service

Jeffrey, Nico,

Jeffrey Altman wrote:
> 
> The Kitten Chair has received a request to submit
> "Stackable Generic Security Service Pseudo-Mechanisms"
> <http://www.ietf.org/internet-drafts/draft-ietf-kitten-stackable-pseudo-mechs-02.txt>
> to the IESG for publication as a Proposed Standard.
> 
> The working group last call will terminate at 00:00 EST 2 November 2006.

I'm sorry, It looks like I missed the last call period.
So I'm sending this to you directly.

Stackable pseudo-mechanisms looks very ambitious to me -- a magnitude
more ambitious than binary plug'n'play with shared libraries.

I can not seriously comment on the document, because I lack the time
to read it carefully and think about it, and I don't have any implementation
or usage experience with this concept.

Two observations:
 - A lot of existing gss-api mechanism do not return a mechanism OID
   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.

 - 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).

   So it would be useful to re-iterate in the description of
   gss_release_oid() that all OIDs from the exiting gss-api v2
   functions are static/readonly and must NOT be passed to
   this new optional function.  The current wording
   "by another GSS-API call, specifically ..." sounds ambiguous
   in a dangerous fashion.

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.

How would a portable application writer benefit from CCM?  Would it
require a gss-api (multi-)mechanism that used these extensions
to provide the benefit in a gss-api v2 transparent fashion?

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten