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: [email protected] [mailto:[email protected]] On Behalf
> Of Dan Harkins
> Sent: Tuesday, March 02, 2010 22:12
> To: Paul Hoffman
> Cc: IPsecme WG; [email protected]
> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
