Subject: Re: Working Group Last Call: Stackable Generic Security Service Pseudo-Mechanisms

From: Jeffrey Altman <[email-masked]>
Date: Fri, 03 Nov 2006 02:03:49 -0500

The Working Group Last Call period is scheduled to expire today.
If you have reviewed this document, please send an e-mail indicating
that you have done so.  A consensus of "silence" cannot be used to
forward a document to the IESG.

Thank you.

Jeffrey Altman

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.
> 
> Abstract
> 
>    This document defines and formalizes the concept of stackable pseudo-
>    mechanisms, and associated concept of composite mechanisms, for the
>    Generic Security Service Application Programming Interface (GSS-API),
>    as well as several utility functions.
> 
>    Stackable GSS-API pseudo-mechanisms allow for the composition of new
>    mechanisms that combine features from multiple mechanisms.  Stackable
>    mechanisms that add support for Perfect Forward Security (PFS), data
>    compression, additional authentication factors, etc... are
>    facilitated by this document.
> 
> A two week Working Group Last Call is being initiated to determine if
> this document is ready for publication.   Positive acknowledgment of
> document review and feedback is requested.
> 
> The working group last call will terminate at 00:00 EST 2 November 2006.
> 
> Jeffrey Altman
> Kitten Chair
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/kitten
_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Nov 2006 17:48:40 +0100 (MET)

Jeffrey, Nico,

> 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