Hi,
I did not cc cfrg on a post I made yesterday, Yaron responded
to it and I have been asked to forward this to the cfrg list to
encourage discussion. Sorry for the confusion. (And if you see
multiple copies of this, sorry about that too, I fat-fingered the
cfrg list the last time).
Dan.
---------------------------- Original Message ----------------------------
Subject: Re: [IPsec] Beginning discussion on secure password-only
authentication for IKEv2
From: "Yaron Sheffer" <yar...@checkpoint.com>
Date: Tue, March 2, 2010 11:04 pm
To: "Dan Harkins" <dhark...@lounge.org>
Cc: "IPsecme WG" <ipsec@ietf.org>
"Paul Hoffman" <paul.hoff...@vpnc.org>
--------------------------------------------------------------------------
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:dhark...@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-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
> >
>
>
>
> 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
