Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

"Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu> Tue, 02 March 2010 18:03 UTC

Return-Path: <uri@ll.mit.edu>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95F528C1FE; Tue, 2 Mar 2010 10:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 gdz0zqSnBJwQ; Tue, 2 Mar 2010 10:03:43 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id A31EE28C1FC; Tue, 2 Mar 2010 10:03:43 -0800 (PST)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id o22I3bmC010198; Tue, 2 Mar 2010 13:03:41 -0500
From: "Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu>
To: "'paul.hoffman@vpnc.org'" <paul.hoffman@vpnc.org>, "'Hannes.Tschofenig@gmx.net'" <Hannes.Tschofenig@gmx.net>
Date: Tue, 02 Mar 2010 13:03:40 -0500
Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Thread-Index: Acq6MQWuh8nCpVjYR+SBTYwCj8rQgwAAarSe
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003020157
Message-Id: <20100302180343.A31EE28C1FC@core3.amsl.com>
X-Mailman-Approved-At: Wed, 03 Mar 2010 07:30:57 -0800
Cc: "'ipsec@ietf.org'" <ipsec@ietf.org>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 18:03:45 -0000

I see value in adding a simpler-than-EAP method, and support this effort. But overall it's an extremely difficult task because of IPR.

I personally would hate to see a patent-encumbered solution - and that would disqualify EKE and PAK outright (both held by Alcatel-Lucent, AFAIK). SRP would be the only acceptable (from IPR point of view) candidate that I'm aware of. I've been told that EKE patent is written so broadly that it could cover SRP as well - somebody more knowledgeable should comment on this.

Tnx!

Regards,
Uri

----- Original Message -----
From: cfrg-bounces@irtf.org <cfrg-bounces@irtf.org>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Cc: IPsecme WG <ipsec@ietf.org>; cfrg@irtf.org <cfrg@irtf.org>
Sent: Tue Mar 02 12:51:29 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

At 7:22 PM +0200 3/2/10, Hannes Tschofenig wrote:
>The challenge I have in understanding the motivation for this work is impacted by ...
>
>1) EAP is not only meant to be used with backend infrastructure.
>2) EAP is an authentication framework and EAP methods exist that support strong-password based authentication.
>3) EAP is implemented by folks in IKEv2 already.
>
>To me it seems that there is the chance to re-use existing mechanisms and to even re-use existing code.

Hannes, it is not really appropriate to re-open closed charter issues. As you know, this was already discussed, at length, in the WG. That's why another part of the new charter has:

- A standards-track IKEv2 extension to allow mutual EAP-based
authentication in IKEv2, eliminating the need for the responder to
present a certificate. The document will define the conditions that
EAP methods need to fulfill in order to use this extension. The
document will recommend, but will not require, the use of EAP methods
that provide EAP channel binding. The proposed starting point for this
work is draft-eronen-ipsec-ikev2-eap-auth-07.txt.

For this thread, please focus on the issues at hand for a secure password-only authentication mode for IKEv2. Thanks!

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg