Subject: [kitten] Consensus Call on Kitten Recharter

From: Shawn Emery <[email-masked]>
Date: Sun, 15 May 2011 22:42:16 -0600

Per kitten WG session discussions in Prague, this starts a consensus 
call for the recharter of the kitten WG.  The call expires in two weeks, 
5/29/11.  Please provide feed-back of the proposed changes, see 
attached.  Members that find the changes adequate then please respond as 
well.  Please give feed-back directly to the list.

Alexey,
Shawn, &
Tom.
--
kitten co-chairs

---

From: Nico Williams <[email-masked]>
Date: Sun, 15 May 2011 23:58:36 -0500

I'm quite interested in two specific extensions:

a) Standardizing the DCE styole option and adding an option for DCE
style negotiation for replay cache avoidance.  Replay cache avoidance
has been adopted in KRB-WG, but the GSS aspects may need to be
reviewed here, or they might even have to be KITTEN work items.

b) A utility function for obtaining an encrypted, exported,
partially-establised security context token, and corresponding utility
function to decrypt and import such a token.  (Cue Martin's
objections.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 May 2011 16:16:30 +0200 (MEST)

Shawn Emery wrote:
> 
> kitten-charter:
> @@ -48,30 +48,27 @@
>    * Provide a more programmer friendly GSS-API for application developers.
>    This could include reducing the number of interface parameters, for
>    example, by eliminating parameters which are commonly used with the
>    default values.

I'm slighty confused by this charter item and what it is supposed to mean.

GSS-APIv2 has been out there as Proposed Standard for 11 years
(actually used for 15 years, and considering that it is fully backwards
 compatible on API calls to GSS-APIv1, its 18 years).

You really don't want to change any of the _existing_ functions and
their parameters at this point, because it would inevitably be backwards
incompatible with _all_ of the installed base.

You could come up with new functions with less parameters that are
easier to use, avoiding any confusion with what is already there.
But actually, the existing GSS-API v2 standard does not require
mechanisms to offer all options that are defined at the API level,
but instead offer only a limited subset, and provides some guidance
to "portable application callers" what subset of features they may
expect to be available from all mechanism, and what may be available
only from a few specific mechanisms.

The only guidance that is really lacking is the guidance about
the absence of the hostbased service name for naming servers.

-Martin

---

From: Shawn Emery <[email-masked]>
Date: Thu, 19 May 2011 00:26:03 -0600

> incompatible with _all_ of the installed base.

This work is item is not about changing existing interfaces, but adding 
additional interfaces that are simplified.

> only from a few specific mechanisms.

My experience is that application developers get this wrong quite often 
resulting in unexpected behavior, memory management issues, etc.  Most 
of these problems could have been avoided by using the correct default 
value or by not having to specify almost half of the arguments to begin 
with.

> the absence of the hostbased service name for naming servers.

I disagree about this being the only issue.

Shawn.
--

---

From: Shawn Emery <[email-masked]>
Date: Thu, 19 May 2011 01:32:53 -0600

> function to decrypt and import such a token.  (Cue Martin's

Are there any volunteers to be authors or contribute to the design of 
said work?

Shawn.
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 May 2011 06:04:03 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> GSS-APIv2 has been out there as Proposed Standard for 11
    Martin> years (actually used for 15 years, and considering that it
    Martin> is fully backwards compatible on API calls to GSS-APIv1, its
    Martin> 18 years).

    Martin> You really don't want to change any of the _existing_
    Martin> functions and their parameters at this point, because it
    Martin> would inevitably be backwards incompatible with _all_ of the
    Martin> installed base.

I agree that we do not want to change the set of parameters that
existing functions take.  Other changes--for example changing semantics,
adding new possibilities of defaults--do not inherently break the entire
installed base.  We would have to carefully consider the impact of any
such change before making it.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 May 2011 06:05:49 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> b) A utility function for obtaining an encrypted, exported,
    Nico> partially-establised security context token, and corresponding
    Nico> utility function to decrypt and import such a token.  (Cue
    Nico> Martin's objections.)

I definitely strongly support standardization work regarding partial
context export.  I'm not sure the encryption should happen in GSS-API
although I'll agree it is likely that is the correct place for it.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2011 12:32:52 -0500

> I'm slighty confused by this charter item and what it is supposed to mean.

We've discussed adding _new_ versions of certain functions with fewer
arguments, for example.

No one, to my knowledge, has yet proposed making
backwards-incompatible changes to the API.  Certainly no one has
proposed changing the C prototypes of GSS-API C bindings, nor the
various types (e.g., gss_buffer_desc), nor any changes to existing
Java bindings methods.  I suppose we might change the abstract API in
such ways, but no one has proposed that either (and I doubt anyone
intends to; certainly I do not).

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 21 May 2011 13:55:03 +0100

>> reviewed here, or they might even have to be KITTEN work items.
I would review this, but not being familiar with details of this I would 
like to get some extra information from Nico about the need for this.

>> function to decrypt and import such a token.  (Cue Martin's
I am happy to work on this one.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 May 2011 22:49:16 +0200

Shawn,

Just so that this is on the record, I would request a change to the
proposed charter, such that the existing draft-ietf-kitten-saml work is
progressed.  The document has completed working group last call with
nary a comment.  We've invested substantial time and effort, and for
many reasons I believe it to be the correct approach.  As I have said
previously, I have no objection to SAML-EC also moving forward, so long
as it doesn't slow the other work.

Eliot

On 5/16/11 6:42 AM, Shawn Emery wrote:
> call for the recharter of the kitten WG.  The call expires in two
> weeks, 5/29/11.  Please provide feed-back of the proposed changes, see
> attached.  Members that find the changes adequate then please respond
> as well.  Please give feed-back directly to the list.
>
> Alexey,
> Shawn, &
> Tom.
> --
> kitten co-chairs
>
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 May 2011 13:14:45 -0400

I'm happy to contribute to the design of the gss partial context stuff.

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 13:58:55 -0500

> I'm happy to contribute to the design of the gss partial context stuff.

Me too.