Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Yaron Sheffer <yaronf@checkpoint.com> Tue, 02 March 2010 20:49 UTC
Return-Path: <yaronf@checkpoint.com>
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 37D6228C18B; Tue, 2 Mar 2010 12:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.174
X-Spam-Level:
X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
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 6QT8i18i3qXc; Tue, 2 Mar 2010 12:49:38 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A3B4228C0CF; Tue, 2 Mar 2010 12:49:37 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o22Knasd018728; Tue, 2 Mar 2010 22:49:36 +0200 (IST)
X-CheckPoint: {4B8D78A6-0-1B201DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 2 Mar 2010 22:49:56 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Dan Harkins <dharkins@lounge.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Date: Tue, 02 Mar 2010 22:49:53 +0200
Thread-Topic: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Thread-Index: Acq6ReTf1vkuZQjHQBCDjhMf6QNooQAAPpmQ
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.com>
References: <p0624081ac7b20a6459c5@[10.20.30.158]> <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net>
In-Reply-To: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [IPsec] 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 20:49:39 -0000
Hi Dan, EAP-EKE supports negotiation of various algorithms, a.k.a. crypto-agility. One of the negotiated algorithms is in fact the group being used. EAP-EKE does require MODP groups that fulfill certain conditions, and as a result, the document defines one such group (additional ones can be easily added). I believe that crypto-agility is an important criterion. As to reuse of IKEv2 groups, this is probably much less important. It is a bit early to speculate about IKE+EKE, since to the best of my knowledge, it has not been written yet. By the way, IKEv2 does allow for negotiation of the DH group using the ugly INVALID_KE_PAYLOAD hack. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Dan Harkins > Sent: Tuesday, March 02, 2010 22:12 > To: Paul Hoffman > Cc: IPsecme WG; cfrg@irtf.org > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > > Hello, > > There are other criteria that should be evaluated in making a > decision, such as how well does the solution fits into IKE(v2) and > does it support "crypto agility". > > RFC 2409 supported negotiation of various parameters, like the group > used for the Diffie-Hellman key exchange. That was removed in RFC 4306. > All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > criteria do some sort of discrete logarithm cryptography and therefore > it would be useful to list whether the candidate algorithm can use > any of the groups either negotiated or asserted by IKE(v2). > > For instance, I do not believe EKE is suitable for any of the > groups currently in the IANA registry of groups that can be used with > IKE(v2). The MODP groups have a generator that is a quadratic residue > which enables a passive attacker to eliminate passwords from the > dictionary if they do not decrypt to a value that is, itself, a > quadratic > residue and ECP groups are unsuitable because a passive attacker can > eliminate passwords from the group if they do not decrypt to a valid > point > on the curve. In either case, after seeing a trivial number of > exchanges > a passive attacker is able to determine the password with high > probability. > > So EKE requires a hard-coded special group to be used for its > discrete > logarithm operations and since negotiation has been removed in RFC 4306 > it means that the ability to change the group to suit the policy or > whim > of the user (what is popularly termed "crypto agility") goes away. EKE > also requires specification of the mode of encryption used which may or > may not be the same as the one negotiated or asserted in IKE(v2). It > could be hard-coded into the specification, like the group, but this > too > further limits "crypto agility". > > The other candidates, I believe, can use the same group, whether MODP > or ECP, that the IKE(v2) exchange is using. I think it would be good to > add these criteria to the draft. > > Also, the table in section 5 should include IEEE 802.11s under the > "standards" column for SPSK. And the phrase "may or may not infringe on > existing patents" applies to all candidates, and frankly, to almost > everything in the IETF. It is a meaningless phrase and it would be > better > to just remove it from the "IPR" column. > > regards, > > Dan. > > On Mon, March 1, 2010 4:34 pm, 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 > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway.
- [IPsec] Beginning discussion on secure password-o… Paul Hoffman
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Hannes Tschofenig
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Paul Hoffman
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yaron Sheffer
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] Beginning discussion on secure passwo… Yaron Sheffer
- Re: [IPsec] Beginning discussion on secure passwo… Paul Hoffman
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] Beginning discussion on secure passwo… Black_David
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Black_David
- Re: [IPsec] Beginning discussion on secure passwo… Yaron Sheffer
- Re: [IPsec] Beginning discussion on secure passwo… Yoav Nir
- Re: [IPsec] Beginning discussion on secure passwo… Tero Kivinen
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] [Cfrg] Beginning discussion on secure… thomwu
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- [IPsec] [Fwd: Re: Beginning discussion on secure … Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Dan Harkins
- [IPsec] [Fwd: Re: Beginning discussion on secure … Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Black_David
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yaron Sheffer
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yoav Nir
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yaron Sheffer