[SECMECH] Desire to standardize some specific EAP mechanisms

Sam Hartman <hartmans-ietf@mit.edu> Thu, 14 July 2005 20:37 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtASn-0000fA-GV; Thu, 14 Jul 2005 16:37:45 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtASl-0000eU-OZ for secmech@megatron.ietf.org; Thu, 14 Jul 2005 16:37:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02672 for <secmech@ietf.org>; Thu, 14 Jul 2005 16:37:41 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org ([] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtAvM-0006yR-A9 for secmech@ietf.org; Thu, 14 Jul 2005 17:07:21 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 997A0E004B; Thu, 14 Jul 2005 16:37:28 -0400 (EDT)
To: secmech@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 14 Jul 2005 16:37:28 -0400
Message-ID: <tsloe95nmyf.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Subject: [SECMECH] Desire to standardize some specific EAP mechanisms
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

Comments from the EAP chairs and the IESG suggest there is a strong
desire to standardize some specific EAP mechanisms probably before the
GUAM work is done.

I think this might be doable particularly if the EAP mechanisms
standardized are things like eap-tls where there are already
alternatives for other frameworks.  The issue is simply one of timing.

The original proposal was to do that work in the EAP working group and
to (depending on BOF results) spin up secmech to do the more general

I'm uncomfortable with that work being done outside the security area.
I'm also uncomfortable with two ongoing parallel efforts without
strong coordination.

I propose that if we want to take that approach we standardize the
specific mechanisms in the secmech group along with doing the more
general work.  For timing reasons we might even need to prioritize
some of the EAP work.  I think there are many advantages to doing so:

1) We become more familiar with the requirements of EAP and the same group of people doing general work get specific practical experience.

2) Since the same group of people are doing both the general and
   specific work you are likely to get better sanity checking across
   the projects.

3) You make sure the efforts don't diverge.

4) You leverage security review experience from the GSS and SASL
   comnunities and practical deployment experience from the EAP community.

If we take that approach, two things need to happen.  First, we need
to get a specific set of mechanisms to standardize early into the
charter.  Second, we would need at least one int-area chair--possibly
one of the existing EAP chairs if willing to serve--by the time a WG
is chartered.

Thanks for your consideration,


SECMECH mailing list