headers
Dan Harkins | 2 Mar 2010 21:12

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
(Continue reading)

Permalink | Reply |
headers
Yaron Sheffer | 2 Mar 2010 21:49
Picon
Favicon

Re: Beginning discussion on secure password-only authentication for IKEv2

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 <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Dan Harkins
> Sent: Tuesday, March 02, 2010 22:12
> To: Paul Hoffman
> Cc: IPsecme WG; cfrg <at> 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".
(Continue reading)

Permalink | Reply |
headers
Dan Harkins | 2 Mar 2010 23:25

Re: 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
(Continue reading)

Permalink | Reply |
headers
Yaron Sheffer | 3 Mar 2010 08:04
Picon
Favicon

Re: Beginning discussion on secure password-only authentication for IKEv2

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 <at> 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
(Continue reading)

Permalink | Reply |
headers
Yoav Nir | 3 Mar 2010 09:14
Picon
Favicon

Re: Beginning discussion on secure password-only authentication for IKEv2

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.

On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote:

> 
> 
> By the way, IKEv2 does allow for negotiation of the DH group using the ugly INVALID_KE_PAYLOAD hack.
> 
> 
>>  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).
Permalink | Reply |
headers
Tero Kivinen | 3 Mar 2010 12:30
Picon
Picon
Favicon

Re: Beginning discussion on secure password-only authentication for IKEv2

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
(Continue reading)

Permalink | Reply |
headers
Paul Hoffman | 2 Mar 2010 22:37

Re: Beginning discussion on secure password-only authentication for IKEv2

At 12:12 PM -0800 3/2/10, Dan Harkins wrote:
>  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".

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

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

OK, but...

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

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?
(Continue reading)

Permalink | Reply |
headers
Dan Harkins | 2 Mar 2010 23:54

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


  Hi Paul,

On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote:
[snip]
>>  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).
>
> OK, but...
>
>>  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.
>
> 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?
(Continue reading)

Permalink | Reply |
headers
Black_David | 3 Mar 2010 00:49

Re: Beginning discussion on secure password-only authentication for IKEv2

Dan,

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

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

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

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
> if the group is good enough to use for the Diffie-Hellman key exchange
> then, by definition, it is good enough for password authentication.
(Continue reading)

Permalink | Reply |
headers
Dan Harkins | 3 Mar 2010 01:48

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


  Hi David,

On Tue, March 2, 2010 3:49 pm, Black_David <at> emc.com wrote:
[snip]
>
> OTOH, I think you've oversimplified here ...
>
>>   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.
>
> 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
(Continue reading)

Permalink | Reply |
headers
Steven M. Bellovin | 3 Mar 2010 01:58

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
"Dan Harkins" <dharkins <at> lounge.org> wrote:

> 
>   Hi David,
> 
> 
> On Tue, March 2, 2010 3:49 pm, Black_David <at> emc.com wrote:
> [snip]
> >
> > OTOH, I think you've oversimplified here ...
> >
> >>   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.
> >
> > 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
(Continue reading)

Permalink | Reply |
headers
Black_David | 3 Mar 2010 02:17

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

> > >>   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.
> > >
> > > 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
(Continue reading)

Permalink | Reply |
headers
Blumenthal, Uri - 0662 - MITLL | 3 Mar 2010 15:25
Picon

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

You're good!  :-)

On the vendor side - perhaps EKE patent concern was the cause (you implement/sell free SRP and get slapped
with EKE licensing)? And the users found alternative solutions in the meanwhile?

Do you think weak passwords are too dangerous overall (many other ways of attacking them outside of direct
protocol attempts that we try to defend against), and so we shouldn't entertain them at all?

Tnx!
Regards,
Uri

----- Original Message -----
From: pgut001 <pgut001 <at> wintermute02.cs.auckland.ac.nz>
To: smb <at> cs.columbia.edu <smb <at> cs.columbia.edu>; Blumenthal, Uri - 0662 - MITLL
Cc: cfrg <at> irtf.org <cfrg <at> irtf.org>; Hannes.Tschofenig <at> gmx.net <Hannes.Tschofenig <at> gmx.net>;
ipsec <at> ietf.org <ipsec <at> ietf.org>; paul.hoffman <at> vpnc.org <paul.hoffman <at> vpnc.org>
Sent: Tue Mar 02 19:41:43 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

"Steven M. Bellovin" <smb <at> cs.columbia.edu> writes:

>Note that the EKE patent expires in October 2011.  (At least I think it does;
>it was filed in October 1991.)  Depending on when you expect implementations
>to appear-- and given how long it takes to produce standards-track documents
>in the IETF -- it might not be a problem.

Given that SRP implementations have been available and more or less freely 
usable for quite some time and TLS-PSK is completely unencumbered anyway, I 
think the real issue won't be "when will implementations appear" but "why
(Continue reading)

Permalink | Reply |
headers
thomwu | 3 Mar 2010 16:47
Picon
Favicon

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

On 3/3/10 6:25 AM, "Blumenthal, Uri - 0662 - MITLL" <uri <at> ll.mit.edu> wrote:

> You're good!  :-)
> 
> On the vendor side - perhaps EKE patent concern was the cause (you
> implement/sell free SRP and get slapped with EKE licensing)? And the users
> found alternative solutions in the meanwhile?

No, I can say that this was definitely not the case in any instances that I
was involved in.  Performance, implementation complexity (of strong password
protocols in general), and protocol complexity ranked much higher on the
list.  Users cared far more about whether strong password protocols degraded
their user experience by adding round trips to the protocol; at that point,
patents were a complete non-issue.

Tom
Permalink | Reply |
headers
Black_David | 3 Mar 2010 21:34

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

This IPR disclosure is relevant to this discussion:
https://datatracker.ietf.org/ipr/63/

Thanks,
--David

> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
Of Blumenthal, Uri - 0662 -
> MITLL
> Sent: Wednesday, March 03, 2010 9:26 AM
> To: 'pgut001 <at> cs.auckland.ac.nz'
> Cc: 'ipsec <at> ietf.org'; 'cfrg <at> irtf.org'
> Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure
password-only authentication for IKEv2
> 
> You're good!  :-)
> 
> On the vendor side - perhaps EKE patent concern was the cause (you
implement/sell free SRP and get
> slapped with EKE licensing)? And the users found alternative solutions
in the meanwhile?
> 
> Do you think weak passwords are too dangerous overall (many other ways
of attacking them outside of
> direct protocol attempts that we try to defend against), and so we
shouldn't entertain them at all?
> 
> Tnx!
> Regards,
(Continue reading)

Permalink | Reply |
headers
Blumenthal, Uri - 0662 - MITLL | 3 Mar 2010 15:30
Picon

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

A reasonable question is - do all the proposed "EKE variations" have the same requirement (and the same
weakness)? Or only the original EKE does?

Regards,
Uri

----- Original Message -----
From: cfrg-bounces <at> irtf.org <cfrg-bounces <at> irtf.org>
To: Dan Harkins <dharkins <at> lounge.org>
Cc: ipsec <at> ietf.org <ipsec <at> ietf.org>; cfrg <at> irtf.org <cfrg <at> irtf.org>; Black_David <at> emc.com
<Black_David <at> emc.com>; paul.hoffman <at> vpnc.org <paul.hoffman <at> vpnc.org>
Sent: Tue Mar 02 19:58:35 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
"Dan Harkins" <dharkins <at> lounge.org> wrote:

> 
>   Hi David,
> 
> 
> On Tue, March 2, 2010 3:49 pm, Black_David <at> emc.com wrote:
> [snip]
> >
> > OTOH, I think you've oversimplified here ...
> >
> >>   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
(Continue reading)

Permalink | Reply |
headers
Steven M. Bellovin | 3 Mar 2010 17:05

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

On Wed, 3 Mar 2010 09:30:53 -0500
"Blumenthal, Uri - 0662 - MITLL" <uri <at> ll.mit.edu> wrote:

> A reasonable question is - do all the proposed "EKE variations" have
> the same requirement (and the same weakness)? Or only the original
> EKE does?
> 
I'm not sure what you mean by "EKE variants" -- all of the variants in
the original paper except for the main one (which was also the first)
-- are now known to be insecure.  Do you mean other PAKE protocols?  I
suspect that any PAKE protocol that relies on the lack of verifiable
plaintext would have the same requirement; the form, however, may
differ.  The specific example I gave in my original note, quoted below,
is specific to EKE, but it's far from the only conceivable attack.
We're going to have to look at any proposal very carefully, with this
in mind.

> ----- Original Message -----
> From: cfrg-bounces <at> irtf.org <cfrg-bounces <at> irtf.org>
> To: Dan Harkins <dharkins <at> lounge.org>
> Cc: ipsec <at> ietf.org <ipsec <at> ietf.org>; cfrg <at> irtf.org <cfrg <at> irtf.org>;
> Black_David <at> emc.com <Black_David <at> emc.com>; paul.hoffman <at> vpnc.org
> <paul.hoffman <at> vpnc.org> Sent: Tue Mar 02 19:58:35 2010 Subject: Re:
> [Cfrg] [IPsec] Beginning discussion on secure password-only
> authentication for IKEv2
> 
> On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
> "Dan Harkins" <dharkins <at> lounge.org> wrote:
> 
> >
(Continue reading)

Permalink | Reply |
headers
Blumenthal, Uri - 0662 - MITLL | 3 Mar 2010 17:43
Picon

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

Yes I mean other protocols potentially covered by EKE patent.

Regards,
Uri

----- Original Message -----
From: Steven M. Bellovin <smb <at> cs.columbia.edu>
To: Blumenthal, Uri - 0662 - MITLL
Cc: 'dharkins <at> lounge.org' <dharkins <at> lounge.org>; 'ipsec <at> ietf.org' <ipsec <at> ietf.org>;
'cfrg <at> irtf.org' <cfrg <at> irtf.org>; 'Black_David <at> emc.com' <Black_David <at> emc.com>;
'paul.hoffman <at> vpnc.org' <paul.hoffman <at> vpnc.org>
Sent: Wed Mar 03 11:05:07 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

On Wed, 3 Mar 2010 09:30:53 -0500
"Blumenthal, Uri - 0662 - MITLL" <uri <at> ll.mit.edu> wrote:

> A reasonable question is - do all the proposed "EKE variations" have
> the same requirement (and the same weakness)? Or only the original
> EKE does?
> 
I'm not sure what you mean by "EKE variants" -- all of the variants in
the original paper except for the main one (which was also the first)
-- are now known to be insecure.  Do you mean other PAKE protocols?  I
suspect that any PAKE protocol that relies on the lack of verifiable
plaintext would have the same requirement; the form, however, may
differ.  The specific example I gave in my original note, quoted below,
is specific to EKE, but it's far from the only conceivable attack.
We're going to have to look at any proposal very carefully, with this
in mind.
(Continue reading)

Permalink | Reply |
headers
Blumenthal, Uri - 0662 - MITLL | 4 Mar 2010 18:08
Picon

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

Well, during my long and fruitful career I've come across many asinine statements - but this pearl from your
collection outshines mine! Indeed "straight from the horse's" (or in the context - "mule's"?) mouth (no
offense meant to those wonderful equestrians).

I'm struck speechless (which is unusual, as anybody who knows me would confirm :-).

Regards,
Uri

----- Original Message -----
From: pgut001 <pgut001 <at> wintermute02.cs.auckland.ac.nz>
To: pgut001 <at> cs.auckland.ac.nz <pgut001 <at> cs.auckland.ac.nz>; Blumenthal, Uri - 0662 - MITLL
Cc: cfrg <at> irtf.org <cfrg <at> irtf.org>; ipsec <at> ietf.org <ipsec <at> ietf.org>
Sent: Wed Mar 03 18:20:53 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

"Blumenthal, Uri - 0662 - MITLL" <uri <at> ll.mit.edu> writes:

>On the vendor side - perhaps EKE patent concern was the cause (you
>implement/sell free SRP and get slapped with EKE licensing)? And the users
>found alternative solutions in the meanwhile?

Nope.  It's been supported in OpenSSL since 0.9.9, but not in any browser.
The reason for not supporting it in Firefox is so astonishingly boneheaded
that I'll quote the original message to make sure that it's straight from the
horse's mouth ("PSK cipher suites" = non-patent-encumbered EKE in TLS-talk):

-- Snip --

Subject: Re: NSS implementation of TLS-PSK/ RFC 4279
(Continue reading)

Permalink | Reply |
headers
suhas manangi | 4 Mar 2010 19:12
Picon

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

Hi all,
I may not be qualified to say this but please correct me if I am wrong.
Having an algorithm which takes user interests into account and generates a key string that is strong enough to do this authentication. Will this serve any purpose?

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply |
headers
Yaron Sheffer | 4 Mar 2010 21:05
Picon
Favicon

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

Can someone please explain the joke to me? Nelson was asked about TLS-PSK (RFC 4279) and he replied that it
can easily be abused. TLS-PSK (similarly to IKE-PSK) is vulnerable to dictionary attacks if used with a
short secret (a.k.a. "password"), at least in the presence of an active attacker. So I think his response
was entirely appropriate. What am I missing?

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Blumenthal, Uri - 0662 - MITLL
> Sent: Thursday, March 04, 2010 19:09
> To: 'pgut001 <at> cs.auckland.ac.nz'
> Cc: 'ipsec <at> ietf.org'; 'cfrg <at> irtf.org'
> Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-
> only authentication for IKEv2
> 
> Well, during my long and fruitful career I've come across many asinine
> statements - but this pearl from your collection outshines mine! Indeed
> "straight from the horse's" (or in the context - "mule's"?) mouth (no
> offense meant to those wonderful equestrians).
> 
> I'm struck speechless (which is unusual, as anybody who knows me would
> confirm :-).
> 
> Regards,
> Uri
> 
> ----- Original Message -----
> From: pgut001 <pgut001 <at> wintermute02.cs.auckland.ac.nz>
> To: pgut001 <at> cs.auckland.ac.nz <pgut001 <at> cs.auckland.ac.nz>; Blumenthal,
> Uri - 0662 - MITLL
> Cc: cfrg <at> irtf.org <cfrg <at> irtf.org>; ipsec <at> ietf.org <ipsec <at> ietf.org>
> Sent: Wed Mar 03 18:20:53 2010
> Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-
> only authentication for IKEv2
> 
> "Blumenthal, Uri - 0662 - MITLL" <uri <at> ll.mit.edu> writes:
> 
> >On the vendor side - perhaps EKE patent concern was the cause (you
> >implement/sell free SRP and get slapped with EKE licensing)? And the
> users
> >found alternative solutions in the meanwhile?
> 
> Nope.  It's been supported in OpenSSL since 0.9.9, but not in any
> browser.
> The reason for not supporting it in Firefox is so astonishingly
> boneheaded
> that I'll quote the original message to make sure that it's straight
> from the
> horse's mouth ("PSK cipher suites" = non-patent-encumbered EKE in TLS-
> talk):
> 
> -- Snip --
> 
> Subject: Re: NSS implementation of TLS-PSK/ RFC 4279
> Date: Tue, 14 Oct 2008 14:01:10 -0700
> From: Nelson B Bolyard <nelson <at> bolyard.me>
> Reply-To: mozilla's crypto code discussion list
> <dev-tech-crypto <at> lists.mozilla.org>
> 
> jengler <at> berkeley.edu wrote, On 2008-10-14 13:52 PDT:
> > I was wondering if implementation of TLS-PSK (RFC 4279) is currently
> in
> > development. I do not see it in the current NSS source or roadmap.
> Thank
> > you for any help.
> >
> > -John Engler
> 
> No.  There are no plans to include any PSK cipher suites in NSS.
> Because of the enormous potential for PSK cipher suites to be
> misused by application developers, there is strong resistance to
> incorporating them into NSS.
> 
> -- Snip --
> 
> As for Microsoft, Opera, etc who knows?  (If you work on, or have
> worked on,
> any of these browsers, I'd like to hear more about why it hasn't been
> considered).  I think it'll be a combination of two factors:
> 
> 1. Everyone knows that passwords are insecure so it's not worth trying
> to do
>    anything with them.
> 
> 2. If you add failsafe mutual authentication via EKE to browsers, CAs
> become
>    entirely redundant.
> 
> So the browser vendors' approach is to ignore EKE and keep on waiting
> for PKI
> to start working, forever if necessary.  "PKI meurt, elle ne se rend
> pas!" [0].
> 
> Peter.
> 
> [0] Hat tip to Luther Martin for the quote :-).
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.
Permalink | Reply |
headers
Yoav Nir | 4 Mar 2010 23:44
Picon
Favicon

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

Explaining a joke spoils all the fun, but here goes:

It's not like PKI is working out better for user authentication.
And password-in-https-form is also vulnerable to online dictionary attacks.
Now if they were using TLS-EAP....
But that, of course, suffers from excessive layering.

________________________________________
From: ipsec-bounces <at> ietf.org [ipsec-bounces <at> ietf.org] On Behalf Of Yaron Sheffer [yaronf <at> checkpoint.com]
Sent: Thursday, March 04, 2010 22:05
To: Blumenthal, Uri - 0662 - MITLL; 'pgut001 <at> cs.auckland.ac.nz'
Cc: 'ipsec <at> ietf.org'; 'cfrg <at> irtf.org'
Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

Can someone please explain the joke to me? Nelson was asked about TLS-PSK (RFC 4279) and he replied that it
can easily be abused. TLS-PSK (similarly to IKE-PSK) is vulnerable to dictionary attacks if used with a
short secret (a.k.a. "password"), at least in the presence of an active attacker. So I think his response
was entirely appropriate. What am I missing?

Thanks,
        Yaron

> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf
> Of Blumenthal, Uri - 0662 - MITLL
> Sent: Thursday, March 04, 2010 19:09
> To: 'pgut001 <at> cs.auckland.ac.nz'
> Cc: 'ipsec <at> ietf.org'; 'cfrg <at> irtf.org'
> Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-
> only authentication for IKEv2
>
> Well, during my long and fruitful career I've come across many asinine
> statements - but this pearl from your collection outshines mine! Indeed
> "straight from the horse's" (or in the context - "mule's"?) mouth (no
> offense meant to those wonderful equestrians).
>
> I'm struck speechless (which is unusual, as anybody who knows me would
> confirm :-).
>
> Regards,
> Uri
>
> ----- Original Message -----
> From: pgut001 <pgut001 <at> wintermute02.cs.auckland.ac.nz>
> To: pgut001 <at> cs.auckland.ac.nz <pgut001 <at> cs.auckland.ac.nz>; Blumenthal,
> Uri - 0662 - MITLL
> Cc: cfrg <at> irtf.org <cfrg <at> irtf.org>; ipsec <at> ietf.org <ipsec <at> ietf.org>
> Sent: Wed Mar 03 18:20:53 2010
> Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-
> only authentication for IKEv2
>
> "Blumenthal, Uri - 0662 - MITLL" <uri <at> ll.mit.edu> writes:
>
> >On the vendor side - perhaps EKE patent concern was the cause (you
> >implement/sell free SRP and get slapped with EKE licensing)? And the
> users
> >found alternative solutions in the meanwhile?
>
> Nope.  It's been supported in OpenSSL since 0.9.9, but not in any
> browser.
> The reason for not supporting it in Firefox is so astonishingly
> boneheaded
> that I'll quote the original message to make sure that it's straight
> from the
> horse's mouth ("PSK cipher suites" = non-patent-encumbered EKE in TLS-
> talk):
>
> -- Snip --
>
> Subject: Re: NSS implementation of TLS-PSK/ RFC 4279
> Date: Tue, 14 Oct 2008 14:01:10 -0700
> From: Nelson B Bolyard <nelson <at> bolyard.me>
> Reply-To: mozilla's crypto code discussion list
> <dev-tech-crypto <at> lists.mozilla.org>
>
> jengler <at> berkeley.edu wrote, On 2008-10-14 13:52 PDT:
> > I was wondering if implementation of TLS-PSK (RFC 4279) is currently
> in
> > development. I do not see it in the current NSS source or roadmap.
> Thank
> > you for any help.
> >
> > -John Engler
>
> No.  There are no plans to include any PSK cipher suites in NSS.
> Because of the enormous potential for PSK cipher suites to be
> misused by application developers, there is strong resistance to
> incorporating them into NSS.
>
> -- Snip --
>
> As for Microsoft, Opera, etc who knows?  (If you work on, or have
> worked on,
> any of these browsers, I'd like to hear more about why it hasn't been
> considered).  I think it'll be a combination of two factors:
>
> 1. Everyone knows that passwords are insecure so it's not worth trying
> to do
>    anything with them.
>
> 2. If you add failsafe mutual authentication via EKE to browsers, CAs
> become
>    entirely redundant.
>
> So the browser vendors' approach is to ignore EKE and keep on waiting
> for PKI
> to start working, forever if necessary.  "PKI meurt, elle ne se rend
> pas!" [0].
>
> Peter.
>
> [0] Hat tip to Luther Martin for the quote :-).
> _______________________________________________
> IPsec mailing list
> IPsec <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.
Permalink | Reply |
headers
Steven M. Bellovin | 3 Mar 2010 01:11

Re: [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

On Tue, 2 Mar 2010 12:12:19 -0800 (PST)
"Dan Harkins" <dharkins <at> lounge.org> wrote:

> 
>   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".
> 
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.)
Permalink | Reply |

Gmane