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

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Tue, 02 March 2010 17:23 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
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 D065128C0E6 for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 09:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level:
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599]
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 EuieHV9MLe1N for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 09:23:07 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 757403A87DF for <ipsec@ietf.org>; Tue, 2 Mar 2010 09:23:06 -0800 (PST)
Received: (qmail invoked by alias); 02 Mar 2010 17:23:03 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp070) with SMTP; 02 Mar 2010 18:23:03 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/3OkkJAn33MsKa6zFLXlbOb/2BHWj4i+OBbkHjRf 8bGmZPYFepGplc
Message-ID: <4B8D494F.8010009@gmx.net>
Date: Tue, 02 Mar 2010 19:22:23 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <p0624081ac7b20a6459c5@[10.20.30.158]>
In-Reply-To: <p0624081ac7b20a6459c5@[10.20.30.158]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.55000000000000004
Cc: IPsecme WG <ipsec@ietf.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 17:23:08 -0000

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.

Ciao
Hannes

Paul Hoffman wrote:
> Greetings again. This message is cross-posted to both the IPsecME WG and the CFRG because it pertains to both groups.
>
> The recently-revised IPsecME charter has a new work item in it:
>
> ==========
> - IKEv2 supports mutual authentication with a shared secret, but this
> mechanism is intended for "strong" shared secrets. User-chosen
> passwords are typically of low entropy and subject to off-line
> dictionary attacks when used with this mechanism. Thus, RFC 4306
> recommends using EAP with public-key based authentication of the
> responder instead. This approach would be typically used in enterprise
> remote access VPN scenarios where the VPN gateway does not usually
> even have the actual passwords for all users, but instead typically
> communicates with a back-end RADIUS server.
>
> However, user-configured shared secrets are still useful for many
> other IPsec scenarios, such as authentication between two servers or
> routers. These scenarios are usually symmetric: both peers know the
> shared secret, no back-end authentication servers are involved, and
> either peer can initiate an IKEv2 SA. While it would be possible to
> use EAP in such situations (by having both peers implement both the
> EAP peer and the EAP server roles of an EAP method intended for "weak"
> shared secrets) with the mutual EAP-based authentication work item
> (above), a simpler solution may be desirable in many situations.
>
> The WG will develop a standards-track extension to IKEv2 to allow
> mutual authentication based on "weak" (low-entropy) shared
> secrets. The goal is to avoid off-line dictionary attacks without
> requiring the use of certificates or EAP. There are many
> already-developed algorithms that can be used, and the WG would need
> to pick one that both is believed to be secure and is believed to have
> acceptable intellectual property features. The WG would also need to
> develop the protocol to use the chosen algorithm in IKEv2 in a secure
> fashion. It is noted up front that this work item poses a higher
> chance of failing to be completed than other WG work items; this is
> balanced by the very high expected value of the extension if it is
> standardized and deployed.
> ==========
>
> As the last paragraph says, there are multiple algorithms to choose from. Different algorithms have different properties. Before the WG decides on which algorithm to focus on, it needs to at least roughly decide which properties are important for the new protocol. I have included the CFRG on this message because they are a good source of expertise on cryptographic properties.
>
> Yaron Sheffer has created a short and admittedly biased draft listing some desired properties and possible candidate algorithms: <http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-pake-criteria-00.txt>. Other people (and even Yaron) might have different views on which properties are important, how the properties should be ranked, the importance of the crypto properties of the listed algorithms, and so on.
>
> This message is therefore meant to kick off the discussion. It is OK for messages to focus on one or more of the proposed algorithms, but getting a clearer view of which crypto and non-crypto properties are important is probably more important first.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>