[SECMECH] Draft Charter

"Salowey, Joe" <jsalowey@cisco.com> Thu, 28 July 2005 04:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy0DQ-0002MZ-IC; Thu, 28 Jul 2005 00:41:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy0DO-0002Ks-FR for secmech@megatron.ietf.org; Thu, 28 Jul 2005 00:41:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03249 for <secmech@ietf.org>; Thu, 28 Jul 2005 00:41:46 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy0in-0006jS-3k for secmech@ietf.org; Thu, 28 Jul 2005 01:14:17 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Jul 2005 21:41:41 -0700
X-IronPort-AV: i="3.95,147,1120460400"; d="scan'208"; a="326706921:sNHT30180100"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6S4fbul018670 for <secmech@ietf.org>; Wed, 27 Jul 2005 21:41:37 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2005 21:46:15 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905944FFD@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: Draft Charter
Thread-Index: AcWTLqbKDFYj1fjZRp+KhohI4GgE0A==
From: "Salowey, Joe" <jsalowey@cisco.com>
To: <secmech@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: quoted-printable
Cc:
Subject: [SECMECH] Draft Charter
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

Here is a draft of a possible sechmech working group charter:

Security Mechanism BoF (secmech)

Security Area Director:
      Sam Hartman <hartmans-ietf@mit.edu>
      Russ Housley <housley@vigilsec.com>

Security Area Advisor:
      Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:
      General Discussion: secmech@ietf.org
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/secmech
      Archive:
http://www.ietf.org/mail-archive/web/secmech/index.html

Description of Proposed Working Group:

There exists a disconnect between the IETF's security frameworks.
Although these frameworks have very similar goals,  the set of
mechanisms available depends upon the choice of framework.  There are a
number of issues that make a compelling case for converging the way we
develop mechanisms for these frameworks.  

- There is a desire to standardized EAP mechanisms and there currently
is no working group with this on its charter. 

- The actual mechanisms in each of these frameworks have very similar
goals of authentication and establishing a cryptographic context. 

- There is pressure to adopt a particular framework because of the set
of mechanisms available not because of the capabilities and upper-layer
interface of the framework.  

- There is a duplication of effort in the development of security
mechanism that support similar credential types and infrastructures.

- Often the cost of deploying a security mechanism is in the
infrastructure and not the implementation of the mechanism itself. There
limited set of mechanisms available to particular frameworks makes the
coordination and administration of security between applications that
use different frameworks more difficult. 

At this time the working group is charter with the following tasks:

- Identify a list of "fast track" EAP mechanism types for
standardization.  Possibly: TLS based mechanism, Pre shared key based
mechanism (it is possible that a single mechanism may meet both
requirements). 

- Standardize fast-track EAP mechanisms

- Document the basic requirements for a mechanism to be a GUAM mechanism

- Document the process for creating a GUAM mechanism

As this work progresses additional work items may be added to the
charter of this group or other working groups such as

- Definition of a common security layer (CFRG?)

- Enhancements to the GSS-API to accommodate GUAM enhancements (Kitten)


Goals and Milestones:

September 2005:  Charter to authorize work on a few fast track
mechanisms and GUAM process
October 2005:    Submit initial draft of base GUAM requirements and
standardization process
October 2005:    Select EAP mechanism approach to fast track
requirements
November 2005:   Submit initial FAST-Track EAP method draft(s)
December 2006:   WG Last Call completes on base requirements and
standardization process, begin working on method standardization 
January 2006:    WG Last Call completes on FAST-Track EAP method drafts
February 2006:   Submit GUAM standardization process as Proposed
Standard 
March 2006:      Submit FAST-Track EAP as proposed standard, update
charter with additional milestones

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech