Re: [sasl] MOGGIES Proposed Charter

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 18 May 2010 17:31 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0DB28C1F9; Tue, 18 May 2010 10:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.923
X-Spam-Level:
X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1GR-24eZT1z; Tue, 18 May 2010 10:31:57 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 017F53A69AA; Tue, 18 May 2010 10:28:00 -0700 (PDT)
Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <S=LOFQBeGZNG@rufus.isode.com>; Tue, 18 May 2010 18:27:51 +0100
Message-ID: <4BF2CDF2.2090600@isode.com>
Date: Tue, 18 May 2010 18:27:14 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Shawn Emery <shawn.emery@oracle.com>
Subject: Re: [sasl] MOGGIES Proposed Charter
References: <4BF221C1.2090005@oracle.com>
In-Reply-To: <4BF221C1.2090005@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, Tim Polk <tim.polk@nist.gov>, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 17:31:59 -0000

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
>