Subject: [IPsec] Beginning the PAKE selection process

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 May 2010 07:42:50 -0700

Greetings again. This WG is chartered to "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 needs to pick one that both is believed to be secure and is believed to have acceptable intellectual property features.

As we discussed earlier, each WG member needs to come up with their own criteria for making such a choice. Dan Harkins has proposed a set of guidelines that individuals might use when choosing; see <http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt>.

So far, three protocols have been proposed to the WG:

-<http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-auth>

-<http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2>

-<http://tools.ietf.org/html/draft-sheffer-ipsecme-hush>

In addition, one more draft was presented to the WG: <http://tools.ietf.org/html/draft-shin-augmented-pake>. However the Augmented PAKE draft does not specify how it would be integrated into IKEv2.

Note that more proposals might be made as we discuss; such proposals will hopefully be accompanied by Internet Drafts that show both the crypto and how it would be integrated into IKEv2.

To start off this conversation, I propose that people start threads on the individual drafts, saying which positive and negative criteria they think apply to each. I also propose that replying to this message, or starting a thread that is supposedly about all four proposals but only focuses on one, is not going to help much. Of course, the authors of the four drafts are welcome to say why they think their proposal meets an optimum set of criteria, and to clarify parts of their proposals as others comment.

Obviously these are all initial drafts, and the WG will have ample opportunity to improve the selected proposal later in the process. For now, please focus on the relative advantages and disadvantages (based on your personal criteria) of each of the proposals.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 24 May 2010 23:07:02 +0300

Hi everyone,

In the past we have had heated discussions on password-based auth. 
Judging by the resounding silence over the last week, only the draft 
authors are interested. If this is true, then the working group as a 
whole is seemingly unable to work on this charter item.

Personally, I would prefer a different outcome. But as a co-chair, I 
would not hesitate to eliminate this work item if there is no community 
support for it.

Thanks,
	Yaron

On 05/17/2010 05:42 PM, Paul Hoffman wrote:
> As we discussed earlier, each WG member needs to come up with their own criteria for making such a choice. Dan Harkins has proposed a set of guidelines that individuals might use when choosing; see<http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt>.
>
> In addition, one more draft was presented to the WG:<http://tools.ietf.org/html/draft-shin-augmented-pake>. However the Augmented PAKE draft does not specify how it would be integrated into IKEv2.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 24 May 2010 14:07:13 -0700 (PDT)

Yaron,

  This is out-of-line. We had discussions on expanding the charter
to include this as a work item and there was sufficient support in
the WG to add it. At the time you argued against it and suggested that
EAP-only was satisfactory. Now that EAP-only has finished WGLC you
now want to revisit killing this work item? I object.

  For reasons that were not apparent (to me at least), the new charter
said that the only draft specifying EAP-only was to be used as a
starting point for the EAP-only work item but the only draft specifying
how to solve the secure PSK work item was not. So the only reason this
"overwhelming silence" didn't greet EAP-only was because this entire step
was short circuited. There wasn't any discussion of EAP-only once it
became work item-- perusing the list shows a whopping zero posts (!) on
it between announcement of the -00 version and the start of WGLC (on the
-02 version)-- yet no one called for its removal.

  I apologize for the tardiness of my post kicking off discussion on my
candidate proposal but I was traveling for the past week-and-a-half and
was otherwise indisposed. Hopefully this will start a discussion but if
it doesn't then I would expect the same treatment of this work item as
that given to EAP-only.

  You seem to alternate wearing your co-chairman's hat or not depending
on what particular tactic you are employing but your strategy remains
the same. I respectfully request that, when it comes to this work item,
you decide whether to wear your WG co-chairman's hat or not and then
stick to it.

  regards,

  Dan.

On Mon, May 24, 2010 1:07 pm, Yaron Sheffer wrote:
>> Greetings again. This WG is chartered to "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 needs to pick
>> one that both is believed to be secure and is believed to have
>> acceptable intellectual property features.
>>
>> As we discussed earlier, each WG member needs to come up with their own
>> criteria for making such a choice. Dan Harkins has proposed a set of
>> guidelines that individuals might use when choosing;
>> see<http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt>.
>>
>> In addition, one more draft was presented to the
>> WG:<http://tools.ietf.org/html/draft-shin-augmented-pake>. However the
>> Augmented PAKE draft does not specify how it would be integrated into
>> IKEv2.
>>
>> Note that more proposals might be made as we discuss; such proposals
>> will hopefully be accompanied by Internet Drafts that show both the
>> crypto and how it would be integrated into IKEv2.
>>
>> To start off this conversation, I propose that people start threads on
>> the individual drafts, saying which positive and negative criteria they
>> think apply to each. I also propose that replying to this message, or
>> starting a thread that is supposedly about all four proposals but only
>> focuses on one, is not going to help much. Of course, the authors of the
>> four drafts are welcome to say why they think their proposal meets an
>> optimum set of criteria, and to clarify parts of their proposals as
>> others comment.
>>
>> Obviously these are all initial drafts, and the WG will have ample
>> opportunity to improve the selected proposal later in the process. For
>> now, please focus on the relative advantages and disadvantages (based on
>> your personal criteria) of each of the proposals.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 May 2010 14:50:23 -0700

At 2:07 PM -0700 5/24/10, Dan Harkins wrote:
>  This is out-of-line.

Would it have been less out-of-line if I, the other co-chair wrote it? Or if someone who is not a co-chair but understands how the IETF process is supposed to work wrote it?

FWIW, I agree with what Yaron wrote. If there is little or no interest in advancing this work other than from the authors of the drafts, we should strongly consider taking it out of the WG charter. You disagree, and others might agree with you or with Yaron.

>it doesn't then I would expect the same treatment of this work item as

Your candidate proposal (and the other two candidate proposals) do not have the same standing as the single EAP-only draft. We are supposed to be choosing one proposal first, then working on that one. If there is not enough interest to even choose a proposal among three (so far) that seem to be reasonably well worked-out, why should we believe that there will be enough interest to adequately review the chosen proposal?

It would be grand if the authors of even one of the various proposals could get enough independent interest in their proposals to show that we can do good work on the charter item. Dan has started a thread on his proposal; I assume Yaron will do so as well. What counts to me is whether others take up the threads with "that sounds right" or "that doesn't meet my criteria for this reason" and so on.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 May 2010 16:54:55 -0500

On Mon, May 24, 2010 at 02:50:23PM -0700, Paul Hoffman wrote:
> Would it have been less out-of-line if I, the other co-chair wrote it?
> Or if someone who is not a co-chair but understands how the IETF
> process is supposed to work wrote it?
> 
> FWIW, I agree with what Yaron wrote. If there is little or no interest
> in advancing this work other than from the authors of the drafts, we
> should strongly consider taking it out of the WG charter. You
> disagree, and others might agree with you or with Yaron.

Personally I'd much rather that the WG add non-PKIX authentication
mechanism options to IKEv2 via existing frameworks: either EAP or the
GSS-API.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 24 May 2010 16:27:01 -0700 (PDT)

Hi Paul,

> Would it have been less out-of-line if I, the other co-chair wrote it?

  Yes. Yaron has a conflict and because of it you said you were handling
this discussion. If you're not happy with the silence then I'd expect
you to ask the WG to provide some constructive input. I didn't expect
the guy with the conflict to propose, "as a co-chair", elimination of
the work item.

> Your candidate proposal (and the other two candidate proposals) do not
> have the same standing as the single EAP-only draft.

  At the time of rechartering they weren't so different though. We had
a discussion on adding two work items and each one had a single individual
submission proposing a way to solve it. One immediately became a WG
document and got the fast track into IETF LC with absolutely no discussion
on the list. The other was put into a process that waited for alternatives
to be written and now requires WG discussion or else it will be eliminated.

  So yea, _now_ the situation is different. But that's because the two
work items were treated so differently from the start. So now I guess
it's the case that we can't treat those two things the same because we're
not treating them the same. Which sort of begs a question.

> It would be grand if the authors of even one of the various proposals
> could get enough independent interest in their proposals to show that we
> can do good work on the charter item.

  I agree!

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 24 May 2010 16:41:59 -0700 (PDT)

Hi Nico,

  We discussed this in the WG. The non-PKIX authentication mechanism
using EAP entails pointless encapsulation, twice as many messages,
unnecessary code bloat from implementation of both client and server
EAP state machines (where it had been the case, in RFC 4306, that an
implementation only needed to do one), and the introduction of problems
that didn't use to exist (like the "lying NAS" problem). The WG added
this work item for a very good reason.

  So how do you think the work item should be solved given that the WG
already decided to solve it? What do you think of my draft?

  Dan.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 May 2010 19:53:14 -0500

> > mechanism options to IKEv2 via existing frameworks: either EAP or the

I didn't say it has to be EAP; I named an alternative.  The GSS-API is
far, far simpler.  For an example see SCRAM (draft-ietf-sasl-scram)
(specifically see the section on SCRAM as a GSS-API mechanism).  (Plus
a GSS->EAP mechanism bridge is certainly feasible as well.)

For your mechanism it'd be even simpler because you'd not be trying to
describe in two different ways at the same time.  SCRAM was designed as
both, a GSS-API mechanism, and as a SASL mechanism that is functionally
equivalent to SCRAM-the-GSS-API- mech-used-as-a-SASL-"GS2"-mech ("GS2"
is a framework for adapting GSS-API mechanisms as SASL mechanisms).

Of course, I'd also point out that SCRAM is the way it is precisely
because we had two camps: one that thought the GSS-API overly complex
and one that thought it pointless to define SCRAM as a SASL mechanism
but not as a GSS-API mechanism.  We found a very happy medium by
constructing a GSS->SASL mechanism bridge that was simple, added no
round-trips and which allowed us to describe SCRAM in two equivalent
ways.  You might find the same is possible here, both with regard to EAP
and with regard to the GSS-API.

You might also find our logic in the SASL WG appealing here as well:
surely you want your mechanism to be useable in more than just this one
context (IKEv2)!, and surely you don't want to have to define new
bindings for it to every application protocol!  By defining your
mechanism as a GSS-API mechanism, for example, you'd get support for the
same mechanism in SSHv2, NFSv4, etcetera, almost for free.

> already decided to solve it? What do you think of my draft?

I've not read it yet.  I don't think it'd make much difference to the
matter at hand.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 May 2010 16:24:38 -0500

A thought about PAKEs and ZKPPs...

In the SASL space we pursued a DIGEST-MD5-like mechanism.  Yup, SCRAM is
vulnerable to off-line dictionary attacks by passive attackers.  Except
that SCRAM is intended to be used with channel binding to TLS, with
confidentiality protection from the same TLS channel, and with TLS
authenticating the server (with PSK, PKIX server certs, doesn't matter
how).

The only difference between the SCRAM-with-channel-binding-to-TLS
approach and a ZKPP is this: with a ZKPP there's no need to separatly
authenticate the server, which means there's no need to deploy a PKI or
Kerberos, nor pre-share certs or keys.  That's pretty nice.

With the SCRAM-with-cb approach you don't really have to deploy a server
authentication infrastructure nor pre-share server authentication
material if you're willing to take a chance on initial attempts: you can
just optimistically learn server authentication material on success.  On
failure you can warn the user to call a helpdesk to reset their
password.  Yeah, that's not as good as what you get with a ZKPP, but
still pretty good.

In practice most customer who'd use a ZKPP would be happy enough to
deploy a server authentication infrastructure in the form of a PKI or
pre-shared certs.  And, they're very likely to want two-factor user
authentication in the form of a user cert (possibly on a smartcard) and
a password.  In the latter case ZKPPs add little value: at best a
round-trip optimization relative to the SCRAM-with-cb approach.

The SCRAM-with-cb approach in IKEv2 would look as follows: first do an
ephemeral-ephemeral DH key exchange, then authenticate the server with a
CERT, then do a GSS-API context establishment with channel binding to
the DH key exchange.

Just a thought!

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 May 2010 18:21:00 -0500

> A thought about PAKEs and ZKPPs...

I should also mention that the benefits of the SCRAM-with-cb
approach: a) simplicity (doesn't get much simpler!), b) this is
completely unencumbered to the best of my knowledge[*].

The one downside is, as I described, the need to separately authenticate
the server to avoid sending material that is suitable for off-line
dictionary attacks to active attackers.  In practice this is easy to
deal with.

[*] SCRAM is based on DIGEST-MD5, which, to the best of my knowledge is
    unencumbered and has had a fruitful deployment store.

    Channel binding goes back to the early 90s (92, I believe) and, to
    the best of my knowledge, is also unencumbered.

Nico
--