Subject: [sasl] Kitten Recharter

From: Shawn Emery <[email-masked]>
Date: Tue, 01 Jun 2010 01:42:54 -0600

Per the recent thead on "MOGGIES Proposed Charter"; I have taken 
suggestions by kitten/SASL WG members and created recharter text for 
Kitten (whilst closing SASL).  Please let me know if I missed anything.

Shawn.
Kitten co-chair.
--

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Jun 2010 18:40:29 +0100

> Kitten (whilst closing SASL).  Please let me know if I missed anything.

Hi Sean,
Thanks for the updated version. This looks much better.
Some additional comments inline.

>Kitten (Common Authentication Technology Next Generation)
>
>
>Description of Working Group:
>
>The Generic Security Services (GSS) API and Simple Authentication and Security
>Layer (SASL) provide various applications with a security framework for secure
>network communication.  The purpose of the Common Authentication Technology
>Next Generation (Kitten) working group (WG) is to develop
>extensions/improvements to the GSS-API, shepherd specific GSS-API security
>mechanisms, and provide guidance for any new SASL-related submissions.
> 
>This working is chartered to specify the following extensions and improvements
>(draft-yu-kitten-api-wishlist-00) to the GSS-API:
>
>* Provide new interfaces for credential management, which include the following:
>	initializing credentials
>	iterating credentials
>	exporting/importing credentials
>
>* Specify interface for asynchronous calls.
>
>* Define interfaces for better error message reporting.
>
>* Provide a more programmer friendly interface for application developers.
>  
>
This point is a bit vague. Do we actually need this as an explicit goal?

>This WG is also chartered to transition proposed SASL mechanisms as
>GSS-API mechanisms:
>
>* A SASL Mechanism for OpenID
>	draft-lear-ietf-sasl-openid-00
>* A SASL Mechanism for SAML
>	draft-wierenga-ietf-sasl-saml-00
>
>The transition from SASL to GSS-API mechanisms will allow a greater set of
>applications to utilize said mechanisms with SASL implementations that support
>the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).
>
>* Shepard draft-melnikov-digest-to-historic through standards track.
>
typo: shephard

>This WG should review proposals for new SASL and GSS-API mechanisms.  The WG
>should also review non-mechanism proposals related to SASL and the GSS-API.
>
I think this is a bit too open-ended for IESG. I would have asked about 
that if I were asked to review such charter ;-).

To be frank, I would delete these 2 sentences, or say the exactly 
opposite: other proposals would require rechartering. However chairs 
always have some flexibility in allowing conversations on related 
topics, as long as this doesn't compromise progress on major deliverables.

>Deliverables:
>
>* GSS-API: initializing credentials
>[editor: TBD]
>
>* GSS-API: iterating credentials
>[editor: TBD]
>
>* GSS-API: exporting/importing credentials
>[editor: TBD]
>
>* GSS-API: specification for asynchronous calls
>[editor: TBD]
>
>* GSS-API: interfaces/improvements for better error message reporting
>[editor: TBD]
>
>* GSS-API: programmer friendly interfaces
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for OpenID
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for SAML
>[editor: TBD]
>
>* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana
>[editor: Nicolas Williams]
>
>* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts
>[editor: Leif Johansson]
>
>* SASL: publish draft-melnikov-digest-to-historic
>[editor: Alexey Melnikov]
>
>Goals and Milestones:
>
>June 2010	Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard
>June 2010	WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana
>July 2010	Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard
>July 2010	First Meeting
>TBD		Other Listed Work Items
>  
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 11 Jun 2010 14:10:42 -0400

>> * Shepard draft-melnikov-digest-to-historic through standards track.

shepherd, with an 'e', please

>> This WG should review proposals for new SASL and GSS-API mechanisms.
>> The WG should also review non-mechanism proposals related to SASL and
>> the GSS-API.
>>
> always have some flexibility in allowing conversations on related topics,
> as long as this doesn't compromise progress on major deliverables.

Not at all.  The intent here is not that the WG have an open-ended mandate 
to take on any and all mechanism work.  However, we want to be clear that 
this is the place to take any such proposals, and that it is in scope for 
the WG to discuss and review them, and to consider whether it wants to work 
on them (in which case a charter revision would be needed).

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Jun 2010 19:13:02 +0100

Jeffrey Hutzelman wrote:

> shepherd, with an 'e', please.

Thanks :-)

>> topics,
> Not at all.  The intent here is not that the WG have an open-ended 
> mandate to take on any and all mechanism work.  However, we want to be 
> clear that this is the place to take any such proposals, and that it 
> is in scope for the WG to discuss and review them, and to consider 
> whether it wants to work on them (in which case a charter revision 
> would be needed).

If that is the intent, then the text is not good enough. It doesn't 
explicitly says that rechartering would be needed, it seems to imply the 
opposite.
It is also not clear to me what can be described as "non-mechanism 
proposals related to SASL and the GSS-API". If we are talking about SASL 
protocol profiles, then we should say that.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 11 Jun 2010 14:49:42 -0400

> protocol profiles, then we should say that.

I don't think it's talking about SASL protocol profiles.  It's talking 
about proposals related to SASL and GSS-API, other than mechanisms.  In 
other words, we're not restricted to considering proposals for new 
mechanisms; we can also consider proposals to do things like adding 
mechanism attribute query to GSS-API or adding the PRF or channel binding 
abstractions to SASL, or whatever else comes along.

I do think it should be in scope for the WG to review and provide expert 
advice on any work which adds SASL or GSS-API support to a new or existing 
protocol.  However, actually _doing_ such work should be explicitly out of 
scope, as that should happen in the appropriate WG for the application 
protocol in question.

-- Jeff

---

From: Shawn Emery <[email-masked]>
Date: Thu, 17 Jun 2010 18:44:08 -0600

> Thanks for the updated version. This looks much better.

Thanks.

>> <snip>

Do you want more details on how this will be accomplished?  For example:

* Provide a more programmer friendly GSS-API for application 
developers.  This could include reducing the number of interface 
parameters, eliminating those whose values' are commonly used.

<snip>
>> The WG
> I think this is a bit too open-ended for IESG. I would have asked 
> about that if I were asked to review such charter ;-).
>

I've read the follow-up thread between you and Hutzelman, and concluded 
that the following clarification should be made:

This WG should review proposals for new SASL and GSS-API mechanisms.  
The WG should also review non-mechanism proposals related to SASL and 
the GSS-API.  However, work that adds SASL or GSS-API support in 
application protocols should be handled by the application's WG.

Shawn.
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Jun 2010 21:22:38 -0400

--On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery 
<[email-masked]> wrote:

> * Provide a more programmer friendly GSS-API for application developers.
> This could include reducing the number of interface parameters,
> eliminating those whose values' are commonly used.
>
> <snip>
> This WG should review proposals for new SASL and GSS-API mechanisms.  The
> WG should also review non-mechanism proposals related to SASL and the
> GSS-API.  However, work that adds SASL or GSS-API support in application
> protocols should be handled by the application's WG.

To the first sentence, add "but may take on work on such mechanisms only 
through a revision of this charter".  Then I think you'll have captured the 
gist of the discussion.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Jun 2010 09:47:30 +0100

>> On 06/11/10 11:40 AM, Alexey Melnikov wrote:
 [...]

>> eliminating those whose values' are commonly used.
*not* commonly used?

Yes, something like that.

>> The
> To the first sentence, add "but may take on work on such mechanisms 
> only through a revision of this charter".  Then I think you'll have 
> captured the gist of the discussion.

+1.