Subject: [IPsec] replacing PSKs: CFRG and PAKE

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Dec 2018 17:48:52 -0500

I'm watching the video (in five minute intervals for unexplained
reasons... it seems like I've been watching this video for days).

I want to +1 Dan: we need a balanced PAKE.

I sincerely wish Tero was right: that there was no excuse not to use digital
signatures for good site-to-site, even between companies.  The reason we
don't have this is because digital signatures keep getting confused with
PKIs, something John Gilmore realized 20 years ago.

I think we should ask the CFRG to pick a single balanced PAKE for us.
If the CFRG want to pick another PAKE for other purposes, that's fine.
I think that letting CFRG pick two PAKEs for different purposes might
free up the log jam?

I also heard Dan offer to remain silent, and I just wanted to get that
on the record.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Dec 2018 17:27:04 -0600

> reasons... it seems like I've been watching this video for days).

Which video?

> I think we should ask the CFRG to pick a single balanced PAKE for us.

They've done so!

https://tools.ietf.org/html/draft-irtf-cfrg-spake2

That specifies one non-augmented, and one augmented PAKE.

I think the I-D is close to ready to publish.  As it happens I sent in
some comments this past weekend.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Dec 2018 22:00:11 -0500

> > reasons... it seems like I've been watching this video for days).

The video of ipsecme from IETF103.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 10 Dec 2018 11:09:25 +0300

Hi Nico,

> > I think we should ask the CFRG to pick a single balanced PAKE for us.

Not so sure. In Bangkok the CFRG just decided to start the 
process of selecting "one or more" (that after discussion 
turned out into "zero or more") recommended PAKE(s).

Regards,
Valery.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 10 Dec 2018 11:22:46 +0300

Hi Michael,

> I think we should ask the CFRG to pick a single balanced PAKE for us.

Why do you think balanced PAKE is more appropriate for us than augmented?

> I think that letting CFRG pick two PAKEs for different purposes might

They've just announced in Bangkok a desire to start the process of selecting
"zero or more" recommended PAKE(s) for IETF community.
I believe IPsec is included :-)

Another problem with PAKE is that it must be integrated into IKE somehow.
EAP definitely can be used for this, but it's a bit expensive from protocol point of view.
We also have RFC  6467, but it's Informational and I'm not sure it's widely supported.
And while the RFC  6467 framework is flexible enough, it is still not clear for me 
if it can accommodate PAKEs like OPAQUE...

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Dec 2018 18:00:18 -0500

> Why do you think balanced PAKE is more appropriate for us than augmented?

Because I share Paul's view that the PSKs we care about are generally
identical in both directions, and this use is primarily about site-to-site
inter-company VPNs.   This is note for road-warrier accesss.

I would prefer that the PAKE method was not wrapped in EAP.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Dec 2018 17:12:40 -0600

> Why do you think balanced PAKE is more appropriate for us than augmented?

Speaking for myself rather than Michael, I think augmented is more
appropriate when the key is based on a memorable password.

However, but transition reasons, it's desirable to support a
non-augmented PAKE with _existing_ password-derived keys.

Also, even for non-password-derived symmetric keys, a PAKE automatically
adds forward security, so it seems like a nice simplification to use a
non-balanced PAKE in all cases where the credentials are shared secret
keys.

So in fact we probably want both.

> I believe IPsec is included :-)

Oh?  I thought the CFRG SPAKE2 I-D was further along.  I'll have to ask
the I-D authors and RG chairs.

In any case, KITTEN WG is moving along with a Kerberos extension to use
the CFRG SPAKE2 protocol -- this is past WGLC and awaiting shepherding
to the IESG now.  If CFRG ultimately picks a different PAKE, or no PAKE,
that could be a problem for the KITTEN work.

> Another problem with PAKE is that it must be integrated into IKE
> somehow.  EAP definitely can be used for this, but it's a bit

Do you mean enrolment and password change protocols?  Enrolment could be
left unspecified, but a password change protocol is required.

> expensive from protocol point of view.  We also have RFC 6467, but

Oh, no, you meant a document like RFC 6467.  Yes, such a document would
be necessary -- I don't think Michael meant to imply otherwise.

> it's Informational and I'm not sure it's widely supported.  And while
> the RFC 6467 framework is flexible enough, it is still not clear for
> me if it can accommodate PAKEs like OPAQUE...

It might be possible to build a single IKE extension that can handle any
number of PAKEs, since they will generally involve a small number of
round trips of exchanges of PAKE-specific octet strings, followed by a
generic key confirmation exchange that involves binding in the PAKE's
transcripts and at least the IKE ID payloads.

There's also the opportunity to add support for second factors (e.g.,
OTPs).  The KITTEN SPAKE work does that, though it's got some issues, so
this WG might not want to copy that approach.

Note that there are all these things to negotiate:

 - PAKE
    - including whether to use a symmetric or augmented variant
 - curve/group
 - second factor

The KITTEN WG SPAKE work did not include PAKE negotiation nor augmented
vs. not-augmented negotiation :(

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Dec 2018 17:20:00 -0600

> inter-company VPNs.   This is note for road-warrier accesss.

There's no reason to not also add support for an augmented PAKE for road
warriors.  It's true that road warriors are already well-supported via
PKIX user certificates, so perhaps there's no need, but it's very little
extra work to support both, augmented and non-augmented.

(Should I be saying "balanced" instead of "non-augmented"?)

> I would prefer that the PAKE method was not wrapped in EAP.

+1

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Dec 2018 18:44:53 -0500 (EST)

On Mon, 10 Dec 2018, Michael Richardson wrote:

> identical in both directions

I agree here.

> , and this use is primarily about site-to-site

But not here. weak group PSK's for roadwarriors is a thing :(

> I would prefer that the PAKE method was not wrapped in EAP.

Indeed. As I explained at the last IETF's presentation, it CANNOT use EAP
because then site-to-site admins cannot use it to connect two different
enterprises because none wants to reconfigure their equipment to trust
the other party's authentication infrastructure.

EAP is not suitable to interconnect different enterprises.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Dec 2018 18:47:25 -0500 (EST)

On Mon, 10 Dec 2018, Nico Williams wrote:

> PKIX user certificates

That is still missing OTP support :(

>, so perhaps there's no need, but it's very little

I'd want the PAKE method to support OTP.

> (Should I be saying "balanced" instead of "non-augmented"?)

Explaining these differences on this list would be useful for me and
possibly others.

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Dec 2018 18:16:24 -0600

> That is still missing OTP support :(

If you have the private keys locked unextractably in a hardware token
that requires a PIN to unlock, then you have two factors right there.
That's not generic two-factor authentication though, and it certainly
isn't OTP.

> I'd want the PAKE method to support OTP.

It's doable.

> Explaining these differences on this list would be useful for me and

A PAKE is a zero-knowledge password proof protocol (ZKPP) that also
provides authenticated key exchange with forward security.  A ZKPP is a
password-based authentication protocol where neither eavesdroppers nor
active attackers get to mount off-line dictionary attacks on captured
protocol material.

I had never seen the word "balanced" used to refer to "not augmented",
but I like it.

A "balanced" PAKE is one where both sides share a secret or secret-
equivalent.

An "augmented" PAKE is a PAKE where the credentials are asymmetric so
that relying parties (servers, acceptors, responders, whatever you call
them) store "verifiers" rather than password-equivalent secrets.

A verifier is much like a hash of a password: not password-equivalent,
but susceptible to off-line dictionary attack.

Compromise of shared secrets (via server compromise) is catastrophic for
a balanced PAKE since until you're able to change all the secrets the
attacker can impersonate all the users to the server.

Compromise of verifiers (via server compromise) is much less disastrous
for an augmented PAKE because you have some time in which to change all
the weak secrets: the time it would take the attacker to recover
passwords via off-line dictionary attack.  The verifiers would all be
salted, naturally, so if your secrets are reasonably strong then that
might be a lot of time to change all those passwords.

A balanced PAKE is symmetric as to initiator/responder roles.  An
augmented PAKE is not quite.

The asymmetry in roles in augmented PAKEs means that in order to
function as an IKE responder (and thus maintain IKE initiator/responder
role symmetry), the IKE PAKE extension would have to permit one side to
request that the other initiate the augmented PAKE exchange.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Dec 2018 19:51:22 -0500

> But not here. weak group PSK's for roadwarriors is a thing :(

yes, typo, "not for road-warrior"

> EAP is not suitable to interconnect different enterprises.

+1.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Dec 2018 20:01:43 -0500

> On Dec 10, 2018, at 19:51, Michael Richardson <[email-masked]> wrote:
> 
> 

I understood. I disagree with the “not”. Road warriors using group psk is a thing, sadly.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Dec 2018 20:58:15 -0500 (EST)

> That's not generic two-factor authentication though, and it certainly

Right. So I guess what I'd like PSK-replacement-PAKE to support is using
OTP, without EAP. But I guess that's not really possible if I understand
things correctly.

With XAUTH, we had a way to transfer a password in an encrypted payload,
and the password could be in the syntax of "<user_password>:<user_token>"

If we are going to basically obsolete/deprecate RFC 6628 and 6467, it
would be nice if we did it in such a way that we can still have OTP
support.

>> I'd want the PAKE method to support OTP.

Great :)

>> Explaining these differences on this list would be useful for me and

Thanks for these.

> augmented PAKE is not quite.

In that case, the gain of augmented PAKE seems small. If the server is
compromised, they can just pretend the AUTH payload is OK if they _want_
you to connect to them and get all your traffic. And the client needs to
know the password, and not just the verifier.

For the case where a VPN gateway should not have the password
credentials itself, it would (should?) be using some kind of EAP
mechanism anyway? So we don't need an augmented PAKE for that?

> request that the other initiate the augmented PAKE exchange.

that feels the wrong method for a site-to-site VPN connecting two
enterprises. One would have a better security after compromise than
the other side?

So it seems to me one balanced PAKE would be enough, but I'll go reread
some older messages again.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Dec 2018 21:20:54 -0500

> I understood. I disagree with the “not”. Road warriors using group psk is a

But they aren't cross-domain, they can do EAP-foobar, and they could use a
certificate without a lot of hassle about what set of trust anchors.

If we stick to the site-to-site then I think we can do something rather
simple and quick, and our security considerations section will be much
simpler.

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Dec 2018 21:01:02 -0600

> OTP, without EAP. But I guess that's not really possible if I understand

No you very much can get PAKE + OTP.  We'll get into the details of what
is difficult later.

> would be nice if we did it in such a way that we can still have OTP

Sure.

> In that case, the gain of augmented PAKE seems small. If the server is

No, the gain of an augmented PAKE is very large.

> compromised, they can just pretend the AUTH payload is OK if they _want_

They can do that in both cases, but in the balanced PAKE case the
attacker who has the shared secret can not only impersonate the server
to the user, but vice-versa, and they can MITM the two.

In the augmented case the attacker who has the verifier can impersonate
the server to the user, but NOT the user to the server (not without
first successfully mounting a dictionary attack on the verifier).

> know the password, and not just the verifier.

The client is always expected to know the password.  The verifier can
always be computed from the password (and salt).

> mechanism anyway? So we don't need an augmented PAKE for that?

EAP has its use: federation.

Augmented PAKE is better than augmented in all cases when dealing with a
username and password as a credential.

Balanced PAKE is only useful (IMO) as a transition tool so that you can
start using the PSK secrets you already have as PAKE secrets then change
passwords to switch to secret/verifier augmented PAKE from that point
forward.

> enterprises. One would have a better security after compromise than

It just means that when the SG/whatever wants to initiate an IKE
exchange with the user it needs an extra message: "Hey yo, start
augmented PAKE with me", followed by the rest of an IKE exchange as if
the now-resonder client had initiated.

> some older messages again.

Please opt for both.  Balanced so you can start using existing PSKs,
augmented so you can better secure the password database on the server
side.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Dec 2018 22:28:39 -0600

> simple and quick, and our security considerations section will be much

I mean, if road warriors should always be using either EAP or user
certs, then we don't need PAKE for anything because presumably the
shared keys used in PSKs are strong enough that PAKEs don't improve
security and only slow things down...

(I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and
8146), yes?)

Assuming you can always use EAP, the only real reasons to use a PAKE in
IKEv2 are:

 - you're not entirely sure that you don't have weak PSKs and would like
   to strengthen them

 - you don't always want EAP for users who don't have certs for reasons
   that escape me

   (I wouldn't object, but if EAP fits the bill as to PAKE already, then
   thw WG could object to spending its resources on adding PAKE to
   IKEv2.)

Right?

Nico
--

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 11 Dec 2018 15:02:51 +0300

Hi Paul,

I think that using PAKE for road warriors is more important than for 
site-to-site VPNs. In the latter case the SGWs are usually administered
by (presumably :-)) experienced administrators, who can select a high-entropy
PSK, and these PSKs need not to be memorable by users. So, generally speaking,
it is more secure to use good PSK than passwords (since any PAKE defends only 
against passive attacks, an attacker can still perform active probes and the search
space is limited for passwords).

So I think that augmented PAKE is more important than balanced. It can be used e.g. 
in those cases when it is impossible to securely store certificate's private key on a 
user devices. I'm not against selecting balanced PAKE too, but I think it's less important.

And I agree that it's better to avoid using EAP for PAKE.

But why do you want to deprecate RFC 6467? It is just a framework that must be
suitable for any PAKE.

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Dec 2018 07:21:26 -0500

> security and only slow things down...

It's the enterprise-to-enterprise connection that is hard to convert to
certificates for the reasons that Paul explained.

>  - you're not entirely sure that you don't have weak PSKs and would like

I think that this is the major reason.

>    thw WG could object to spending its resources on adding PAKE to

I think that a user-oriented PAKE is more useful if it can be backended into
a AAA infrastructure, which EAP can.
A site-to-site PAKE is more useful if it isolated from any AAA
infrastructure.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Dec 2018 07:23:05 -0500

> it is more secure to use good PSK than passwords (since any PAKE defends

If we assume highly competent administrators, then we don't need a PAKE
at all.   What I heard from the IPsecME record was that many in the room
felt that this was where ther was a weakness.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 11 Dec 2018 15:48:52 +0300

> at all.   

For remote access where certificates or raw public key cannot
be used, PAKE is extremely useful.

> What I heard from the IPsecME record was that many in the room

I see this as a social issue, not a technical one. We can't prevent
administrators from being careless, either with PSKs or with passwords.

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Dec 2018 14:25:19 -0600

On Tue, Dec 11, 2018 at 07:21:26AM -0500, Michael Richardson wrote:
> > > But they aren't cross-domain, they can do EAP-foobar, and they
> > > could use a certificate without a lot of hassle about what set of
> > > trust anchors.
> > >
> > > If we stick to the site-to-site then I think we can do something
> > > rather simple and quick, and our security considerations section
> > > will be much simpler.
> >
> It's the enterprise-to-enterprise connection that is hard to convert
> to certificates for the reasons that Paul explained.

Is it not better to think of it as federation?  Is it not federation?

> I think that this is the major reason.

OK, but you can always convert the real weak PSKs to either PK-{I,raw}
or EAP depending on whether the "client" is a user or not and/or its
capabilities.

I'e, this reason doesn't seem pressing, unless what's pressing is that
somehow a non-EAP PAKE would be much less work for some implementors or
operators (or users) than EAP (w/ EAP-PWD or equivalent).

The moment someone says "and let's add OTP" I think EAP is definitely
the better answer if it already ticks all the capability boxes.

> I think that a user-oriented PAKE is more useful if it can be
> backended into a AAA infrastructure, which EAP can.

I tend to agree.  The only case where that's not true is when you have a
site that doesn't already have RADIUS/DIAMETER/WHATEVER AAA
infrastructure and would rather not deploy one.  Not sure the WG should
cater to such users.

> A site-to-site PAKE is more useful if it isolated from any AAA

Sure, but does this WG want to cater to that?

I think a reasonable compromise would be to add a PAKE (both options,
balanced and augmented) but no second factor support.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Dec 2018 15:57:34 -0500 (EST)

> or EAP depending on whether the "client" is a user or not and/or its

I hate the idea of turning weak PSKs, possibly already logged by nation
states, and turn these into PAKEs. I would really hope people do NOT do
that or part of the point of obsoleting PSK's for PAKEs is lost.

> operators (or users) than EAP (w/ EAP-PWD or equivalent).

Yes. Please no EAP where possible.

> the better answer if it already ticks all the capability boxes.

That I can agree too. In general, the OTP use case is a really a
deployment with a human driver in the seat, and not site-to-site or
mesh-node encryption. It's almost always remote access vpn within the
same organisation.

>>>    thw WG could object to spending its resources on adding PAKE to

As explained before. site to site has no way of doing EAP in practise.

> infrastructure and would rather not deploy one.  Not sure the WG should

That is a common case, imagine your 4 home users connecting back to your
simple home vpn gateway.

> Sure, but does this WG want to cater to that?

Yes we do! One of the goals was to get PSK phased out. So to me this is
the primary use case.

> balanced and augmented) but no second factor support.

I have been convinced this is likely the right way forward.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Dec 2018 20:35:23 -0500 (EST)

> administrators from being careless, either with PSKs or with passwords.

We can make more secure deployments easier.

If the only change on the site-to-site config is to change the keyword
"psk" to "pake" and that prevents offline dictionary attacks, that's an
easy win.

I care a little less for group psk's because well, it is a group so even
a pake won't buy us that much extra if dozens or thousands of people
have the pake secret.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 12 Dec 2018 12:02:44 +0300

> "psk" to "pake" and that prevents offline dictionary attacks, that's an

I'm not so sure. Replacing PSK with password+PAKE could in fact decrease security.
Properly chosen PSK provides high level of protection against both passive
and active attacks. On the other hand, PAKE, as far as I know,
only makes it difficult for passive eavesdropper to perform offline
dictionary attack. But an active attacker may still try out all possible
password values (due to small search space). Yes, you can easier
detect active attackers and block them (and site-to-site VPNs
usually have fixed IPs, that simplifies the task), but I still feel a bit uncomfortable
by the idea of replacing perfectly secure crypto mechanism with a weaker one. 
I'd rather educate administrators :-) And note, that no PAKE will
save you if administrators will select passwords like "foobar" or "12345".

I think that PAKE is a very good mechanism for remote access
in situation when certificates (or raw public keys) cannot be used
for various reasons. E.g. f simple CPE that has no memory
to securely store private key.

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Dec 2018 22:52:20 +0200

Hi, Valery

> On 12 Dec 2018, at 11:02, Valery Smyslov <[email-masked]> wrote:
> 

I don’t think the idea is to replace a 128-bit PSK derived from a properly seeded DRBG with “ip5ecmeRockz!” using a PAKE.

I think we’re assuming the administrator will configure “ip5ecmeRockz!” (or “foobar”) regardless of what we call it, so we might as well give them a better mechanism to use this value.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Dec 2018 16:36:34 -0500

Yoav Nir <[email-masked]> wrote:
> I don’t think the idea is to replace a 128-bit PSK derived from a properly
> seeded DRBG with “ip5ecmeRockz!” using a PAKE.

Please! The official PSK is "makemetastegoat"