Re: [AAA-DOCTORS] draft-ietf-ipsecme-eap-mutual-03.txt

David Mitton <david@mitton.com> Fri, 18 June 2010 16:45 UTC

Return-Path: <david@mitton.com>
X-Original-To: aaa-doctors@core3.amsl.com
Delivered-To: aaa-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0083A687E for <aaa-doctors@core3.amsl.com>; Fri, 18 Jun 2010 09:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.459
X-Spam-Level: *
X-Spam-Status: No, score=1.459 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
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 fD1TH3ZKtoyO for <aaa-doctors@core3.amsl.com>; Fri, 18 Jun 2010 09:45:34 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by core3.amsl.com (Postfix) with ESMTP id 577833A68EA for <aaa-doctors@ietf.org>; Fri, 18 Jun 2010 09:45:33 -0700 (PDT)
Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 19C409C3B1B for <aaa-doctors@ietf.org>; Fri, 18 Jun 2010 16:45:38 +0000 (UTC)
X-Panda: scanned!
X-Session-Marker: 6461766964406D6974746F6E2E636F6D
X-Filterd-Recvd-Size: 7557
Received: from webmail10 (imap-ext [216.40.42.5]) (Authenticated sender: david@mitton.com) by omf08.hostedemail.com (Postfix) with ESMTP for <aaa-doctors@ietf.org>; Fri, 18 Jun 2010 16:45:37 +0000 (UTC)
Received: from 128.221.197.57 ([128.221.197.57]) by webmail10 (Tucows Webmail) with HTTP; Fri, 18 Jun 2010 16:45:37 +0000 (GMT)
Date: Fri, 18 Jun 2010 16:45:37 +0000
From: David Mitton <david@mitton.com>
To: aaa-doctors@ietf.org
Message-ID: <385778386.11163.1276879537776.JavaMail.mail@webmail10>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [128.221.197.57]
Subject: Re: [AAA-DOCTORS] draft-ietf-ipsecme-eap-mutual-03.txt
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: david@mitton.com
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 16:45:35 -0000

Sorry,

  I know I'm past yesterday's telechat with this item, but I still wanted to air this issue to this group, FWIW.
(first I had to find where I had sent it from and then move to the mailbox I'm subscribed from)

 

Since I sent the email below, I got a couple comments, and EAP-POTP was added to the list in the current draft.

So my squeak got greased, but I still don't think this is the right way to go about this.

 

Thanks,

Dave.

 

_____________________________________________
From: Mitton, Dave
Sent: Thursday, April 08, 2010 11:17 AM
To: pasi.eronen@nokia.com; Hannes.Tschofenig@gmx.net; yaronf@checkpoint.com
Cc: aland@deployingradius.com; jsalowey@cisco.com; David Mitton
Subject: RE: draft-ietf-ipsecme-eap-mutual-00.txt

 

 

Pasi, Hannes, Yaron,

                I'm looking at this draft you have authored, and am a bit dismayed by the table in section 4, "Allowed EAP Methods"

with the sentence

 
"Methods not listed below (or in the IANA registry that extends this list) MUST NOT be used with the

   mechanism defined here."

 

The method we support here at RSA Security, EAP-POTP (RFC 4793) I believe meets the criteria of this draft, and I'm not happy by be excluded without reason.

It's not clear what criteria you used to generate this list, perhaps other than personal familiarity.

 

I would also pick a nit with your definition of "Allows Channel Binding".   If you want to distinguish Identity protection, then re-label it.

EAP-POTP has several Channel Binding and Cryptographic bindings techniques in it, which don't relate to directly to the identity.

 

In general, I'm sure I don't like the idea of burying an obscure evaluation of other EAP methods in a document without review by a wider audience.

I would prefer to see a set of criteria and/or required security properties instead of a list generated from a small number of authors.

 

This doesn't feel like something an open standard should be doing to other EAP developers.   

 

 

David Mitton

RSA Security Division of EMC, Inc.