Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Yaron Sheffer <yaronf@checkpoint.com> Wed, 03 March 2010 07:03 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 4918728C14B for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 23:03:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.13
X-Spam-Level:
X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-0.131, 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 VV5lZUgYE0wn for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 23:03:53 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 833E428C223 for <ipsec@ietf.org>; Tue, 2 Mar 2010 23:03:53 -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 o2373rsd012486; Wed, 3 Mar 2010 09:03:53 +0200 (IST)
X-CheckPoint: {4B8E089A-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; Wed, 3 Mar 2010 09:04:13 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Dan Harkins <dharkins@lounge.org>
Date: Wed, 03 Mar 2010 09:04:12 +0200
Thread-Topic: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Thread-Index: Acq6V1qhDsqRwC78SwmBTqGEKDF1wwARtSig
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56F1@il-ex01.ad.checkpoint.com>
References: <p0624081ac7b20a6459c5@[10.20.30.158]> <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.com> <15cec0967fa816093466c3e2986ea728.squirrel@www.trepanning.net>
In-Reply-To: <15cec0967fa816093466c3e2986ea728.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>, Paul Hoffman <paul.hoffman@vpnc.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: Wed, 03 Mar 2010 07:03:55 -0000
Hi Dan, I consider reuse of DH groups a minor issue at best. But yes, it's a valid criterion. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, March 03, 2010 0:26 > To: Yaron Sheffer > Cc: Dan Harkins; Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > > Hi Yaron, > > The discussion is on the secure password-only authentication work > item > in which a password authenticated key exchange is being added directly > to IKE(v2). It doesn't matter what EAP-EKE does or does not do because > EAP is not being used for this work item. > > Now we can add some sort of negotiation or assertion of the special > group required by EKE (analagous to what EAP-EKE does) but that doesn't > fit well with IKEv2 today. > > Whether the ability to use the existing IANA group registry or > whether > hard-coding special groups into the exchange is less or more important > is a matter of opinion and when we get to that stage we can argue about > it. But right now all I'm saying is that this should be included in the > criteria that we are using to evaluate candidates. Do we need a shoe > horn > or a jack hammer to put the exchange into IKE(v2)? Once in does it > constrain us in any way? These are valid topics to discuss. Don't you > agree? > > regards, > > Dan. > > On Tue, March 2, 2010 12:49 pm, Yaron Sheffer wrote: > > 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 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