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-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Tuesday, March 02, 2010 22:12 >> To: Paul Hoffman >> Cc: IPsecme WG; c...@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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
