Subject: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Mar 2010 16:34:12 -0800

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Mar 2010 19:22:23 +0200

The challenge I have in understanding the motivation for this work is 
impacted by ...

1) EAP is not only meant to be used with backend infrastructure.
2) EAP is an authentication framework and EAP methods exist that support 
strong-password based authentication.
3) EAP is implemented by folks in IKEv2 already.

To me it seems that there is the chance to re-use existing mechanisms 
and to even re-use existing code.

Ciao
Hannes

Paul Hoffman wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Mar 2010 09:51:29 -0800

At 7:22 PM +0200 3/2/10, Hannes Tschofenig wrote:
>The challenge I have in understanding the motivation for this work is impacted by ...
>
>2) EAP is an authentication framework and EAP methods exist that support strong-password based authentication.
>To me it seems that there is the chance to re-use existing mechanisms and to even re-use existing code.

Hannes, it is not really appropriate to re-open closed charter issues. As you know, this was already discussed, at length, in the WG. That's why another part of the new charter has:

- A standards-track IKEv2 extension to allow mutual EAP-based
authentication in IKEv2, eliminating the need for the responder to
present a certificate. The document will define the conditions that
EAP methods need to fulfill in order to use this extension. The
document will recommend, but will not require, the use of EAP methods
that provide EAP channel binding. The proposed starting point for this
work is draft-eronen-ipsec-ikev2-eap-auth-07.txt.

For this thread, please focus on the issues at hand for a secure password-only authentication mode for IKEv2. Thanks!

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 2 Mar 2010 12:12:19 -0800 (PST)

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.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 2 Mar 2010 22:49:53 +0200

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-masked] [mailto:[email-masked]] On Behalf
> Of Dan Harkins
> Sent: Tuesday, March 02, 2010 22:12
> To: Paul Hoffman
> Cc: IPsecme WG; [email-masked]
> Subject: Re: [IPsec] Beginning discussion on secure password-only
> authentication for IKEv2
> 
> 
>   Hello,
> 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Mar 2010 13:37:50 -0800

>does it support "crypto agility".

...and what we mean by "agility". To some, that means "in-protocol negotiation of parameters", but to others it means "have enough variants of the algorithm with different parameters to meet some security threshold".

>any of the groups either negotiated or asserted by IKE(v2).

OK, but...

>a passive attacker is able to determine the password with high probability.

Those two paragraphs don't line up. Why would you want to use the groups negotiated or demanded in the IKEv2 exchange if they allow for easier attacks? Wouldn't it be better to allow the PAKE to negotiate or demand its own, presumably better, groups?

>further limits "crypto agility".

Yaron disagreed with this assessment. I would like to hear from others with EKE experience.

>add these criteria to the draft.

See above. I think the requirement should be "crypto agility, which means X Y Z" unless that agility itself opens up a security hole, such as a downgrade attack.

>to just remove it from the "IPR" column.

+1

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 2 Mar 2010 14:25:43 -0800 (PST)

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.
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 2 Mar 2010 14:54:43 -0800 (PST)

Hi Paul,

On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote:
[snip]
> Those two paragraphs don't line up. Why would you want to use the groups
> negotiated or demanded in the IKEv2 exchange if they allow for easier
> attacks? Wouldn't it be better to allow the PAKE to negotiate or demand
> its own, presumably better, groups?

  The candidate exchanges all rely on the "hard problem" of doing a
discrete logarithm in one of the defined groups. It's the same "hard
problem" that makes the Diffie-Hellman portion of IKE secure. If the
group negotiated or demanded in IKE allows for an "easier attack" then
it shouldn't be used in the IKE exchange to do the Diffie-Hellman. And
if the group is good enough to use for the Diffie-Hellman key exchange
then, by definition, it is good enough for password authentication.

  If someone wants to use a 521-bit ECP group for the Diffie-Hellman key
exchange then requiring him to use a 2048-bit MODP group for authentication
seems a bit odd and constraining. It would make more sense, to me at least,
if the same 521-bit ECP group was used for authentication. Substitute the
group based on your own policy or whim-- 192-bit ECP, 8192-bit MODP,
1024-bit MODP-- and it's still odd and constraining to be forced to use
a different one for authentication.

  I think there is value in being able to use the same group (a lesson
learned from IKEv1 is that not everything needs to be negotiated and the
increase in complexity just isn't worth it). Some may find value in
negotiating groups separately. Whatever. But I think this should be
included in the criteria for selection so we can discuss the pros and
cons.

> Yaron disagreed with this assessment. I would like to hear from others

  Yaron points out that EAP-EKE negotiates the special group but we're
not using EAP here so the point he makes is neither here nor there.

> See above. I think the requirement should be "crypto agility, which means
> X Y Z" unless that agility itself opens up a security hole, such as a
> downgrade attack.

  No downgrade attacks. I agree. An attacker will go after the weakest
point. Which in this case has to be repeated active guessing attack
(which should be easy enough to notice and deal with).

  regards,

  Dan.

---

From: <[email-masked]>
Date: Tue, 2 Mar 2010 18:49:29 -0500

Dan,

> >>IKE(v2).

There was an analogous experience with SRP for iSCSI - completely different groups were used up to 2048 bits and beyond there, the modulus primes from the larger IKEv2 groups were combined with different generators (i.e., not 2) - see Appendix A of RFC 3723.

[... snip ...]

OTOH, I think you've oversimplified here ...

> it shouldn't be used in the IKE exchange to do the Diffie-Hellman. 

If I follow your logic, I think you're arguing that because the existing groups allow easier attacks on password authentication (e.g., based on checks on what a guessed password decrypts to) then they allow easier attacks on IKE with existing authentication, *hence* those groups are unacceptable to use with IKE.  I think the *hence* is off the mark due to the much larger candidate search space when other techniques (e.g., certificate-based) are used to authenticate.

> And

No argument here, but I don't think that statement implies its converse.

[... snip ..]

> included in the criteria for selection so we can discuss the pros and

I would agree with that - the ability to use the existing groups should be a plus for evaluation.

I'd also suggest that if new groups are defined for password authentication, those groups ought to be usable for IKE as well *provided that* the resulting negotiation complexity doesn't get out of hand.  I don't think we can retire/replace the existing groups, and I don't think you're suggesting that.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Tuesday, March 02, 2010 5:55 PM
> To: Paul Hoffman
> Cc: IPsecme WG; [email-masked]; Dan Harkins
> Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
> 
> 
>   Hi Paul,
>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 2 Mar 2010 19:11:46 -0500

On Tue, 2 Mar 2010 12:12:19 -0800 (PST)

> does it support "crypto agility".
There are certainly many things that need to be considered, including
how, specifically, a particular algorithm can be embedded into an
engineered framework.  Any solution that requires a single,
fixed-for-all-time modulus and base is, to me, unacceptable.  (That was
the problem with SKIP, way back when.)

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 2 Mar 2010 16:48:07 -0800 (PST)

Hi David,

On Tue, March 2, 2010 3:49 pm, [email-masked] wrote:
[snip]
> If I follow your logic, I think you're arguing that because the existing
> groups allow easier attacks on password authentication (e.g., based on
> checks on what a guessed password decrypts to) then they allow easier
> attacks on IKE with existing authentication, *hence* those groups are
> unacceptable to use with IKE.  I think the *hence* is off the mark due to
> the much larger candidate search space when other techniques (e.g.,
> certificate-based) are used to authenticate.

  That wasn't what I was arguing. I think all the candidate exchanges
are based on the computational Diffie-Hellman assumption. And the
work factor to attack them on that front should be the same as the
work factor to attack a standard Diffie-Hellman key exchange. Or am
I missing something?

  I don't think any of the currently-defined groups are unacceptable
to use with IKE. But hypothetically, if there was some group defined
that allowed an easy attack (the order was unacceptably small, for
instance) then it would be unsuitable for IKE just like it would be
unsuitable for any of the candidate password authentication schemes.

  For these password authentication schemes to be secure, the only method
of attack is repeated active guessing attacks of the password (the
advantage an attacker gains is through interaction, not computation).
An "easier attack" is an off-line dictionary attack to learn the password
(the advantage gained is through computation) and using any of the groups
in IKE(v2)'s IANA registry with EKE would enable a dictionary attack.
But the attacker doesn't learn the ephemeral secret that results from
EKE, the CDH assumption still applies. The issue isn't with the group,
per se, it's with the (mis)use of the group.

  regards,

  Dan.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 2 Mar 2010 19:58:35 -0500

On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
"Dan Harkins" <[email-masked]> wrote:

> >> discrete logarithm in one of the defined groups. It's the same
> >> "hard problem" that makes the Diffie-Hellman portion of IKE
> >> secure. If the group negotiated or demanded in IKE allows for an
> >> "easier attack" then it shouldn't be used in the IKE exchange to
> >> do the Diffie-Hellman.
> >
> > If I follow your logic, I think you're arguing that because the
> > existing groups allow easier attacks on password authentication
> > (e.g., based on checks on what a guessed password decrypts to) then
> > they allow easier attacks on IKE with existing authentication,
> > *hence* those groups are unacceptable to use with IKE.  I think the
> > *hence* is off the mark due to the much larger candidate search
> > space when other techniques (e.g., certificate-based) are used to
> > authenticate.
> 
>   For these password authentication schemes to be secure, the only
> method of attack is repeated active guessing attacks of the password
> (the advantage an attacker gains is through interaction, not
> computation). An "easier attack" is an off-line dictionary attack to
> learn the password (the advantage gained is through computation) and
> using any of the groups in IKE(v2)'s IANA registry with EKE would
> enable a dictionary attack. But the attacker doesn't learn the
> ephemeral secret that results from EKE, the CDH assumption still
> applies. The issue isn't with the group, per se, it's with the
> (mis)use of the group.
> 
Right.  In the original EKE paper, we called this a "partition
attack".  There are others possible; it's important to take care to
avoid them.  For example, suppose that we wanted a ~2048-bit -- 256 byte
-- modulus.  Choosing a modulus of 2040 bits, though about the same
difficulty when it comes to solving discrete log, is unacceptable for
EKE, because in a correct guess the high-order byte would be all zeros;
an incorrect guess would, with probability 255/256, let you rule out a
candidate password.  A good EKE modulus would be close enough to 2^2048
to have a negligible probability of a decryption with a bad guess being
in the range [p, 2^2048-1].  In other words, good moduli for EKE have
specialized properties.

---

From: <[email-masked]>
Date: Tue, 2 Mar 2010 20:17:44 -0500

> in the range [p, 2^2048-1].  In other words, good moduli for EKE have

That's roughly what I understood - good groups for EKE should be good
groups for IKE, but good groups for IKE (e.g., the existing groups) are
not necessarily good groups for EKE because they may not have the
specialized properties required to block additional attacks on EKE that
don't apply to IKE.

It appears like Dan agrees, so I may have misinterpreted what he
originally wrote.

Thanks,
--David

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 3 Mar 2010 09:04:12 +0200

Hi Dan,

I consider reuse of DH groups a minor issue at best. But yes, it's a valid criterion.

Thanks,
	Yaron

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Wednesday, March 03, 2010 0:26
> To: Yaron Sheffer
> Cc: Dan Harkins; Paul Hoffman; IPsecme WG
> > By the way, IKEv2 does allow for negotiation of the DH group using
> the
> > ugly INVALID_KE_PAYLOAD hack.
> >
> > Thanks,
> > 	Yaron
> >
> >> > Greetings again. This message is cross-posted to both the IPsecME
> WG
> >> and
> >> > As the last paragraph says, there are multiple algorithms to
> choose
> >> from.
> >> > Different algorithms have different properties. Before the WG
> decides
> >> on
> >> > Yaron Sheffer has created a short and admittedly biased draft
> listing
> >> some
> >> > 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
> >> > clearer view of which crypto and non-crypto properties are
> important
> >> is

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Mar 2010 10:14:07 +0200

Yes, you can sort-of negotiate DH groups, but you don't have the "New Group Mode" that we had in section 5.6 or RFC 2409.

So with RFC 4306, you're stuck with only those groups that appear in the IANA registry, rather than your own pet DH groups.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Mar 2010 13:30:22 +0200

Yoav Nir writes:
> Yes, you can sort-of negotiate DH groups, but you don't have the
> "New Group Mode" that we had in section 5.6 or RFC 2409. 

Yes, that was left out but as it was seen that nobody will accept new
group proposed from unknown party without checking it first, and
checking that the modulus is prime and otherwise secure is quite hard
task... 

> So with RFC 4306, you're stuck with only those groups that appear in
> the IANA registry, rather than your own pet DH groups.

That is not completely true. RFC4306 has a SHOULD requirement which
says:

----------------------------------------------------------------------
				   ... In support of this goal, all
   implementations of IKEv2 SHOULD include a management facility that
   allows specification (by a user or system administrator) of Diffie-
   Hellman (DH) parameters (the generator, modulus, and exponent lengths
   and values) for new DH groups.  Implementations SHOULD provide a
   management interface via which these parameters and the associated
   transform IDs may be entered (by a user or system administrator), to
   enable negotiating such groups.
----------------------------------------------------------------------

I.e. as it was seen that implementations will not want to accept group
they have not verified, and that verification is computationally
costly operation, it will not be done online. So if you want to use
your own private groups you use off-line communication and communicate
the group parameters to the other side and both ends store that group
parameters along with the group number allocated from private number
space, and then you can use the privete group.
-- 
[email-masked]