Re: [sasl] MOGGIES Proposed Charter

[Alexey Melnikov <[e-mail]>]

Shawn Emery wrote:

> As discussed; attached is the proposed charter text for a new working 
> group (MOGGIES) based on future direction in the GSS-API and SASL 
> space.  Please provide any feed-back to the lists by the end of May.

Thanks for writing a proposal.
My comments below (without my AD hat):

> Thank you,
>
> Shawn Emery and Tom Yu (co-chairs)

-------------------------------------------------

>MOGGIES (Mechanisms Of Generating Generically Interoperable & Effective
>Security)
>
>
>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 Mechanisms Of Generating Generically
>Interoperable & Effective Security (MOGGIES) working group (WG) is to develop
>extensions/improvements to the GSS-API, shepherd specific GSS-API security
>mechanisms, revise SASLprep with a stringprep profile from the NewPrep WG,
>
I think that SASLPrep should be done in the proposed newprep WG. There 
might be some bits that might be done in MOGGIES, but at this point I am 
not convinced there are any.

I am Ok with the rest of your list.

>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.
>
>* Specify an interface for reporting the security strength of GSS-API mechanism.
>
>* Provide a more programmer friendly interface for application developers.
>
>This working group is also chartered to transition proposed SASL mechanisms as
>GSS-API mechanisms:
>  
>
What does this mean? Do you mean that they become GS2 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 (RFC 5801).
>
RFC 5801 hasn't been published yet. So I don't think we should reference it.

>The working group shall also revise SASLprep with a stringprep profile developed
>by the NewPrep WG.
>  
>
See above.

>This working group will review SASL related submissions as well, including any
>new SASL mechanisms proposed.
>
IMHO, this is a bit open ended for IESG.
Should we restrict this to SASL mechanisms, or are we saying that 
updates to SASL protocol profiles are also in scope? I think the answer 
is probably "no", although they should be reviewed here.

On a somewhat related note: is there still any interest in publish 
"DIGEST-MD5-to-historic" document, or should I request its publication 
outside of a Sec Area WG?

>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: reporting security strength
>[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]
>
>* SASL: Revise SASLprep with stringprep from the NewPrep WG
>[editor: TBD]
>
>
>Goals and Milestones:
>
>July 2010	First Meeting
>
>TBD		Listed Work Items
>