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

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Thu, 4 Mar 2010 12:08:43 -0500

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 <[email-masked]>
To: [email-masked] <[email-masked]>; Blumenthal, Uri - 0662 - MITLL
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
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" <[email-masked]> 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 <[email-masked]>
Reply-To: mozilla's crypto code discussion list
<[email-masked]>

[email-masked] 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 :-).

---

From: suhas manangi <[email-masked]>
Date: Thu, 4 Mar 2010 23:42:44 +0530

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?

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 4 Mar 2010 22:05:57 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Blumenthal, Uri - 0662 - MITLL
> Sent: Thursday, March 04, 2010 19:09
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> 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).
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 5 Mar 2010 08:27:36 +0200

Hi Peter,

I completely agree with the rest of the argument. But I don't know of a realistic way to do it with TLS-PSK (people will *always* use short passwords, it's not like it's the exception to the rule). TLS-SRP is one possible solution. Or, as Yoav suggests, TLS-EAP with several alternatives, including EAP-PWD and EAP-EKE. In some interesting cases, EAP-AKA might also be appropriate.

Unfortunately the IAB thinks that TLS-EAP is Bad Bad Bad (http://tools.ietf.org/html/draft-iab-auth-mech-07#section-10.2.4). So it's back to PKI. Sigh.

Thanks,
	Yaron

> From: pgut001 [mailto:[email-masked]] On Behalf
> Of Peter Gutmann
> Sent: Friday, March 05, 2010 2:07
> To: [email-masked]; [email-masked]; Yaron Sheffer
> Cc: [email-masked]; [email-masked]
> Subject: RE: [IPsec] [Cfrg] Beginning discussion on secure password-
> Yaron Sheffer <[email-masked]> writes:
> 
> >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?
> 
> Thinking through the rest of the argument, which is:
> 
> - We currently have a (supposedly) multi-billion dollar global industry
> built
>   around the total failure of the existing browser authentication
> model.
> 
> - Mutual authentication, in which the server has to prove knowledge of
> the
>   user's credentials before the user can connect, would cause a serious
>   headache for phishers.
> 
> - The FF developers have chosen not to implement this because, in the
> special-
>   case situation where it's done really badly, it could theoretically
> be
>   abused (note the special-case qualification of "if used with a short
>   secret", for which the answer is "well don't do that, then").
> 
>   This is balanced against the currently-used model which pretty much
> doesn't
>   work at all right out of the box, no matter what you do with it.
> 
> - Phishers the world over breathe a sigh of relief, and business
> continues as
>   usual.
> 
> Peter.
>