Re: [SECMECH] Desire to standardize some specific EAP mechanisms

"T. Charles Clancy" <> Fri, 15 July 2005 11:32 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1DtOR1-0002G2-4T; Fri, 15 Jul 2005 07:32:51 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1DtOQz-0002E3-NW for; Fri, 15 Jul 2005 07:32:49 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id HAA26558 for <>; Fri, 15 Jul 2005 07:32:48 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1DtOtm-0004t0-Si for; Fri, 15 Jul 2005 08:02:36 -0400
Received: from ( []) by (8.12.10/8.12.5) with ESMTP id j6FBWb1q022658; Fri, 15 Jul 2005 07:32:37 -0400 (EDT)
Date: Fri, 15 Jul 2005 07:32:37 -0400 (EDT)
From: "T. Charles Clancy" <>
To: Sam Hartman <>
Subject: Re: [SECMECH] Desire to standardize some specific EAP mechanisms
In-Reply-To: <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

As an author of EAP-PAX, I've been frustrated with the standards track 
options available.  Doing the work in the EAP WG is the fastest route to 
RFC.  IMHO, there is sufficient security talent within the EAP WG to 
guarantee quality protocol development.

I certainly understand the concerns about diverging or duplicate work; 
however, my biggest concern is the overhead time.  I've been trying to get 
standards-track action for EAP-PAX for 8 months.  I suppose the existince 
of this conversation indicates progress, but I'm not enthusiastic about 
waiting another year or so.  If the proposed approach can be done in a 
timely manner, then I'm all for it.

[ t. charles clancy ]--[ ]--[ ]
[ computer science ]-----[ university of maryland | college park ]

On Thu, 14 Jul 2005, Sam Hartman wrote:

> 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
> work.
> 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,
> --Sam
> _______________________________________________
> SECMECH mailing list

SECMECH mailing list