Subject: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2

From: Stephen Hanna <[email-masked]>
Date: Wed, 13 Apr 2011 19:09:42 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines a password authentication protocol for IKEv2
based on PACE (Password Authenticated Connection Establishment).

I am neither a cryptographer nor an expert on IPsec or IKEv2.
Given these limitations, I will say that I found the Security
Considerations section of the document to be thorough. All of
the security issues that I could come up with and more were
addressed in a credible manner. Overall, the document is clear
and well-written. Personally, I do not have any concerns with
this document becoming an RFC. However, it might be wise to
wise to have a cryptographer or expert in authentication protocols
provide an independent review of the document, if that has not
already been done. If it has been done, I have no concerns.

Thanks,

Steve Hanna

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Apr 2011 10:04:42 +0300

Hi Steve,

thanks for your review.

This document was published on the ipsecme list. During Last Call we 
received comments form Dan Harkins, who is certainly "an expert in 
authentication protocols."

The cryptographic part (PACE) has been published in the past, both as an 
academic paper and as a component of another standard. Both are 
referenced in the draft.

Thanks,
	Yaron

On 04/14/2011 02:09 AM, Stephen Hanna wrote:
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 10:38:32 -0500

[Resend.  Forgot to reply-all.]

On Thu, Apr 14, 2011 at 2:04 AM, Yaron Sheffer <[email-masked]> wrote:
> academic paper and as a component of another standard. Both are referenced
> in the draft.

PACE does not use a standard PBKDF.  That's not necessarily a problem,
of course, but it could be.  There's no iteration count, for example,
in the SPwd nor KPwd derivations (an iteration count belongs in the
SPwd derivation, if anything).  Nor is there any password salting(!),
nor any discussion regarding the absence of salting.  The lack of
salting should be considered fatal, IMO.  The lack of an iteration
count is less significant, but I'd still rather see an iteration
count.  Note that negotiating a salt and iteration count requires an
extra round-trip.  And note that iteration count negotiation has
security considerations.

Of course, PACE is targeting Experimental... do we care about
cryptographic issues in Experimental RFCs?  I'd say we should, though
less so than for Standards Track RFCs since we can only spare so much
energy.

I'm rather disappointed to see this wheel reinvented.  SCRAM (RFC5802)
would fit right in instead of PACE, for example, and has the same
kinds of properties as PACE, but with a number of advantages over PACE
(SCRAM is on the Standards Track, received much more review, uses a
PBKDF with salt and iteration count, is implemented, is reusable in
many contexts, does channel binding, there's an LDAP schema for
storing SCRAM password verifiers, ...).

We, secdir, should be encouraging wheel reuse wherever possible over
wheel reinvention.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Apr 2011 09:00:45 -0700

> less so than for Standards Track RFCs since we can only spare so much

If we "care about" such things, they should be discussed on open mailing lists, particularly if you are criticizing academic publications related to the document.

> We, secdir, should be encouraging wheel reuse wherever possible over

"We" never have encouraged that. Many of "us" are chairs of WGs whose charters explicitly allow or mandate the opposite of what you are proposing. If you want a change, it has to come from the ADs, not from "us".

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 11:29:07 -0500

> If we "care about" such things, they should be discussed on open mailing lists, particularly if you are criticizing academic publications related to the document.

I'm not sure what you mean.  I cc'ed all, and reviewers are supposed
to cc authors, so the authors should have a copy of my reply.  Also,
over on the IPsec list we've been discussing password-based mechanisms
(though not this one, yet, because I didn't know it was progressing so
fast).  Since I just became aware of these issues as a result of a
secdir posting, that's where I replied.

Are you suggesting that secdir reviews should always be cc'ed to the
lists where the I-Ds in question were first reviewed?  Or that
responders to secdir reviews should do so?  Did I do something wrong?
Really?

> "We" never have encouraged that. Many of "us" are chairs of WGs whose charters explicitly allow or mandate the opposite of what you are proposing. If you want a change, it has to come from the ADs,…

"We", secdir, are volunteers.  This volunteer would rather avoid wheel
reinvention, and this volunteer, perhaps naively, had hoped others
would agree.  Perhaps other volunteers disagree (you do).  I
explicitly referred to secdir, not WG chairs, not ADs, nor did I refer
to actual current practice, but rather stated an opinion of what we
ought to do.

All that aside, is it really the case that "we" (secdir) don't mind
the lack of salting?  Really?!  In 2011, four decades or so since the
invention of salting?  Or did you really just mean to criticize me for
not cc'ing the IPsec list on my reply?

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Apr 2011 19:51:17 +0300

I'm sorry Nico, I simply don't understand where the rant in the second 
part of your mail is coming from.

A few days ago you bombarded the ipsec mailing list with your opinions 
on authentication infrastructure (some of which I happen to share), 
without taking the time to figure out the context: the set of drafts 
that the WG consciously decided NOT to pursue and that finally are able 
to progress.

I'm amazed at the comparison of PACE with SCRAM. In a previous mail you 
pointed out yourself that SCRAM is vulnerable to on-the-wire dictionary 
attacks, which PACE is not. The IETF had never managed to standardize 
any ZKPP methods until just recently (with the exception of TLS-SRP), 
and finally we're doing something about it, even if on the Experimental 
track. I believe this counts as a positive contribution to the security 
of the Internet.

I agree that salting the stored password (SPwd) would have improved the 
security of this protocol (unlike iteration counts). And it can be added 
with no extra round trips, since it's not "negotiated", just sent by the 
responder. My coauthor and I need to consider the benefits vs. costs, 
since the major use case here is not open servers, more often it would 
be VPN gateways.

Thanks,
     Yaron

On 04/14/2011 06:38 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 2:04 AM, Yaron Sheffer<[email-masked]>  
> wrote:
> referenced

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 11:54:19 -0500

On Thu, Apr 14, 2011 at 11:39 AM, Dennis Kügler
<[email-masked]> wrote:
> "Standard" PBKDF are used to artifically enhance the entopy of the password,
> because low-entropy passwords are easy targets for dictionary attacks. PACE
> is a cryptographic protocol that is designed to (mathematically) withstand
> (passive) dictionary attacks independent of the strength of the password and
> therefore there is no need for additional countermeasures like salting the
> password.

Salting is still useful regarding password verifier security.  Recall
that salting was originally invented for that purpose, long before the
first challenge/response password protocols were invented.

> Actually, the protocols have very different properties. SCRAM (more or less)
> requires a public key infrastucture in place, while PACE provides an
> authenticated and encrypted channel without any additional security layer.

As far as I can tell PACE provides a secure but not authenticated
channel.  In Figure 1 I don't see anything that would authenticate the
channel other than the shared secret (derived from a password).  There
is a KE exchange however, which protects PACE against passive attacks,
but not against active attacks.  Did I miss something else?  If not
then iteration counts add some value, no?

Also, regarding SCRAM, yes, it's intended to be used, ideally, with a
secure, authenticated channel and channel binding to that channel.
This is not unlike what PACE does, actually, except that PACE builds
that channel itself -- but why do that when IKE can already do that
anyways?  Or, another way to phrase that: you could have done the same
thing with SCRAM, something like:

I->R: HDR, SAi1, KEi, Ni, <password mech negotiation>
R->I: HDR, SAr1, KEr, Nr, <password mech negotiation>
I<->R: <SCRAM with channel binding to the channel setup above>

You get the same properties this way as in PACE, plus salting, plus
iteration counts.  Plus a Standards Track solution.  Plus
specification and code reuse.  Plus less reviewing to do because the
security analysis becomes simpler because the security analysis for
SCRAM has been done.

> Once you decide to abandon those simple and insecure password-based
> challenge/response protocols, feel free to make use of PACE instead of
> reinventing the wheel :-)

SCRAM is no less secure than PACE when used as intended: with channel
binding to a secure channel, and arguably (that is, I'm arguing this)
it's more secure than PACE.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Apr 2011 09:56:49 -0700

On Apr 14, 2011, at 9:29 AM, Nico Williams wrote:

> I'm not sure what you mean.  

I mean that the closed secdir mailing list is not an appropriate place to be discussing proposed problems with crypto protocols if the intended result is that they protocols will change or that serious design discussions happen.

> I cc'ed all, and reviewers are supposed
> to cc authors, so the authors should have a copy of my reply.  

That is not an open discussion, that forces people who are not on this mailing list to go through intermediaries.

> Also,

No problem there: I was discussing what "we" should do if "we" want discussions to have results.

> responders to secdir reviews should do so?  Did I do something wrong?

No, no, no, and no.

> to actual current practice, but rather stated an opinion of what we

Most people on secdir are here because they are chairs of WGs in the Security Area. Maybe you are thinking of the old secdir model. :-)

> invention of salting?  

I read the paper in the PACE document and thought that it covered the design well. I even looked for follow-ups to the paper and found none (although some may have appeared since I looked). Maybe I'm naive, but I tend to assume that academic review of crypto papers on which there is also discussion in IETF WGs is sufficient for publishing something as an Experimental RFC. 

> Or did you really just mean to criticize me for

No. If I meant to do that, I would have. This proposal has already been discussed in the WG for a bit over a year.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 11:57:49 -0500

On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer <[email-masked]> wrote:
> attacks, which PACE is not. The IETF had never managed to standardize any
> ZKPP methods until just recently (with the exception of TLS-SRP), and
> finally we're doing something about it, even if on the Experimental track. I
> believe this counts as a positive contribution to the security of the
> Internet.

This betrays a fundamental misunderstanding of SCRAM and channel binding.

SCRAM with channel binding to a secure channel is as secure as PACE,
and arguably more so.

If you do not understand what I just wrote then you need to read RFCs
5056, 5929, and 5802 -- in that order.

> responder. My coauthor and I need to consider the benefits vs. costs, since
> the major use case here is not open servers, more often it would be VPN
> gateways.

Salting with a username requires no negotiation, but then you can't
rename users without also changing their passwords (a minor issue).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 12:06:13 -0500

> I mean that the closed secdir mailing list is not an appropriate place to be discussing proposed problems with crypto protocols if the intended result is that they protocols will change or that ser…

It is not closed:

http://www.ietf.org/mail-archive/web/secdir/current/maillist.html

I remember the secdir meeting where opening the archives (though not
past archives) was decided :)

> Most people on secdir are here because they are chairs of WGs in the Security Area. Maybe you are thinking of the old secdir model. :-)

Perhaps I don't belong here any longer then?  And yes, I'm thinking of
the old secdir model.  When was it abandoned?  (We both seem to be out
of date then regarding secdir practices!)

> I read the paper in the PACE document and thought that it covered the design well. I even looked for follow-ups to the paper and found none (although some may have appeared since I looked). Maybe I…

It may be sufficient, but nothing says that having had WG review no
further review is applicable, even for an Experimental RFC (for
example, the IESG can always issue a do-not-publish request to the
RFC-Editor, even if the I-D in question received WG review and passed
WGLC).

> No. If I meant to do that, I would have. This proposal has already been discussed in the WG for a bit over a year.

The whole point of secdir review (and IETF review) is to catch things
that might not have been caught within a WG.  Forgive me for being
late to this party, but here I am.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 14 Apr 2011 10:21:44 -0700 (PDT)

Hi Nico,

On Thu, April 14, 2011 9:57 am, Nico Williams wrote:
>> any

  PACE does not require a secure channel to be passed through. In fact,
the way it's used there is no security (yet), it's just an unauthenticated
Diffie-Hellman that "protects" the channel that PACE is done through.
PACE performs authentication of the IKE SA by doing a ZKPP and adding the
authenticated and shared secret result of the ZKPP into the result of the
unauthenticated Diffie-Hellman (plus assorted cruft).

  regards,

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Apr 2011 20:24:00 +0300

I am unfamiliar with SCRAM, and never claimed otherwise. I just quoted 
your own analysis during the ipsec ML discussion. *Still* not having 
read the documents, I'd like to remind you that any auth protocol over 
IKE is vulnerable to passive attackers until authentication is complete, 
channel binding or not.

We can apply random salt, not just salt with the user name, because the 
PACE "action" only starts at the *second* exchange of IKEv2. So we can 
piggyback a salt payload along with the Responder's notification that it 
supports the protocol.

Thanks,
	Yaron

On 04/14/2011 07:57 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer<[email-masked]>  wrote:

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 12:25:13 -0500

> unauthenticated Diffie-Hellman (plus assorted cruft).

In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a "channel".

There seems to be a terminology disconnect.  As a result of this
disconnect you and others are discarding the work of others (e.g.,
SCRAM in this case) without understanding it in the first place.

I can't force you to read RFC5056 and become familiar with the notion
of channel binding.  But I do wish you'd give it a go.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 12:32:04 -0500

On Thu, Apr 14, 2011 at 12:24 PM, Yaron Sheffer <[email-masked]> wrote:
> I am unfamiliar with SCRAM, and never claimed otherwise. I just quoted your
> own analysis during the ipsec ML discussion. *Still* not having read the
> documents, I'd like to remind you that any auth protocol over IKE is
> vulnerable to passive attackers until authentication is complete, channel
> binding or not.

Not if you encrypt the relevant bits with the session key agreed via
the KE payloads (which PACE sure does, near as I can tell, since the
"ENONCE" is sent protected by the session key: "IKE_PACE: HDR, SK{IDi,
[IDr,], SAi2, TSi, TSr, ENONCE, PKEi}").

But the protocol is vulnerable to an active attack.  If you
authenticate the responder with PKIX first then PACE would not be
vulnerable even to an active attack.  Certainly an option to be able
to authenticate the responder this way would be nice.

> We can apply random salt, not just salt with the user name, because the PACE
> "action" only starts at the *second* exchange of IKEv2. So we can piggyback
> a salt payload along with the Responder's notification that it supports the
> protocol.

Ah, good point.  SCRAM would not allow you to get that one round-trip
optimization because it'd be an abstraction violation to run its
initial round-trip in parallel with the KE exchange then add in the
channel binding in the second round-trip of SCRAM.  *This* could be a
good reason to not use SCRAM (though I won't concede that just yet),
but the points regarding salting and iteration count remain.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 14 Apr 2011 10:35:50 -0700 (PDT)

Hi Nico,

  One other thing...

On Thu, April 14, 2011 9:57 am, Nico Williams wrote:
>> since

  I'm not sure that salting really buys anything. This is not a client-
server protocol; either side can initiate to each other. So both sides
need an _identical_ representation of the credential to authenticate with.
If there is some agreed-upon salt then the salted password becomes
the credential to use. This is no different than just using an unsalted
password. The nonces from the IKE exchange are used in PACE to provide
additional randomness to its particular use of the password.

  regards,

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 12:41:57 -0500

> additional randomness to its particular use of the password.

This is important.  I hadn't realized that PACE was intended to be
initiated in either direction.  When one of the peers is a device
acting on behalf of a user (who knows just a their username and
password) and the other is a system that has access to SPwd (the
shared secret derived from the password), then it's important that the
peer that sends the ENONCE first be the device where the user is at,
else the active attack on PACE gets much simpler (since impersonating
the user device is probably simpler than impersonating the other one).

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 14 Apr 2011 10:47:51 -0700 (PDT)

Hi Nico,

On Thu, April 14, 2011 10:25 am, Nico Williams wrote:
>> Â PACE does not require a secure channel to be passed through. In fact,

  I don't think there's a terminology disconnect. Yes, it's a "channel",
but the important thing is it's not a "secure channel", which is what
you said above.

  SCRAM is not resistant to off-line dictionary attack, PACE is. So
the work of others has not just been ignorantly discarded, it is just
not appropriate to use in this particular case.

  What is needed here is to parlay a low-entropy password into a
secure secret without anything else. There is no way to "authenticate
the responder with PKIK" (as you implied in another email) because
there is nothing else that could be used in accordance with any PKIK RFC.
Using SCRAM here would be more secure than the broken PSK mode of IKE(v2)
today but would not be resistant to off-line dictionary attack.

  Don't think of this as a username/password protocol. There is no
real "user". There is just a password and the two side have to prove
to each other they know it without leaking any information about it
to each other or an adversary. SCRAM isn't the right tool for this job.

  regards,

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 12:59:38 -0500

> but the important thing is it's not a "secure channel", which is what

I'm distinguishing secure from authenticated.  If the channel can
provide confidentiality and integrity protection then it's secure.  If
it's authenticated that's even better.

> not appropriate to use in this particular case.

I don't see how the ENONCE in PACE is resistant to off-line dictionary
attacks.  What am I missing?

I stand by my assertion that SCRAM with channel binding to the KE
exchange, and protected by that KE exchange, is protected against
passive attacks, and if the channel is authenticated, then it's also
protected against active attacks.  (Note that I never proposed SCRAM
w/o CB, nor would I have.)

If I'm right that ENONCE is resistant to off-line dictionary attacks
then I stand by my assertion that SCRAM (with CB) is at least as
secure as PACE, and arguably more so.

> today but would not be resistant to off-line dictionary attack.

I understand that PKIX credentials will not always be available for
either, much less both of the peers (if they are available for both
then the only thing the password adds is an additional authentication
factor, and is probably an undesirable complication).  However, I
expect that a certificate will often be available for "servers".  As
for SCRAM, again, _with_ CB it's no weaker than PACE.

> to each other or an adversary. SCRAM isn't the right tool for this job.

If there's no user and the password is randomly generated then I have
no concerns whatever.

However, everything in the I-D leads me to believe that the password
is intended to be memorable to human users.  For example, why bother
with stringprep if the password is intended to be a randomly generated
string?  Why bother with Unicode at all in that case?  Moreover, the
introduction specifically refers to weak shared secrets, which leads
me to believe that PACE is specifically intended for user
authentication.

So which is it?  Is PACE just an improved PSK mechanism?  Or is PACE a
password-based mechanism as we normally think of them (i.e., for human
users)?

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Apr 2011 21:25:42 +0300

Hi Nico,

ENONCE in and of itself is not vulnerable to an off-line dictionary 
attack because the password encrypts a random bit string, and we take 
care that there is no stray entropy (padding, MAC) that such an attacker 
could use.

As to the bigger question of why the protocol as a whole is not 
vulnerable to the attack, you will have to follow the proof in the paper 
(or maybe just ask my coauthor).

And regarding the usage scenario: the primary scenario is password-based 
machine-to-machine authentication. Yes, sysadmins are human (in most 
cases :-) and they tend to use short passwords for machine auth, much 
more often than we would have liked.

There is a secondary use case that's the usual human-to-server auth, 
where the peers are too lazy to use EAP. I'm questioning whether this 
scenario is interesting enough to add a salted "mode" into the protocol.

Thanks,
	Yaron

On 04/14/2011 08:59 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 12:47 PM, Dan Harkins<[email-masked]>  wrote:

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 13:44:09 -0500

On Thu, Apr 14, 2011 at 1:25 PM, Yaron Sheffer <[email-masked]> wrote:
> ENONCE in and of itself is not vulnerable to an off-line dictionary attack
> because the password encrypts a random bit string, and we take care that
> there is no stray entropy (padding, MAC) that such an attacker could use.

But the ENONCE paired with the AUTH payloads is subject to off-line
dictionary attacks (the attacker will have to have impersonated the
responder in order to obtain the necessary material).

> As to the bigger question of why the protocol as a whole is not vulnerable
> to the attack, you will have to follow the proof in the paper (or maybe just
> ask my coauthor).

It sounds like you're asserting that PACE is a ZKPP.  Is that right?

> machine-to-machine authentication. Yes, sysadmins are human (in most cases
> :-) and they tend to use short passwords for machine auth, much more often
> than we would have liked.

You might want to clarify this in the abstract and introduction then.
But even so, as long as the passwords are human memorable and the
mechanism is not a ZKPP, then my other comments stand.  However, if
this is really for machine authentication then I'll be happy with text
exhorting admins to pick good passwords.

> There is a secondary use case that's the usual human-to-server auth, where
> the peers are too lazy to use EAP. I'm questioning whether this scenario is
> interesting enough to add a salted "mode" into the protocol.

Fair enough.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Apr 2011 22:46:50 +0300

Yes, PACE is a ZKPP, and the AUTH payloads depend on values that the 
attacker cannot compute (PACESharedSecret). Again, this assertion is 
based on the mathematical proof of the protocol.

We have tried for many years to educate people to use better passwords. 
This has not worked. So we'd better assume that passwords are weak by 
default, and if they're good, all the better.

Thanks,
	Yaron

On 04/14/2011 09:44 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 1:25 PM, Yaron Sheffer<[email-masked]>  wrote:

---

From: Tom Yu <[email-masked]>
Date: Thu, 14 Apr 2011 16:51:23 -0400

> based on the mathematical proof of the protocol.

Given Nico's comments, perhaps the fact that PACE is a ZKPP should be
made more obvious earlier in the document.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 15:58:55 -0500

> made more obvious earlier in the document.

Yes please.  I really needed to see figure 1 from the paper.  I also
needed to read section 4.2 of the I-D.

This is a clever ZKPP.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 16:13:06 -0500

So, I'm embarrassed.  Please ignore all my earlier comments on this.

Having read the paper, and the sections I'd missed in the I-D, I
believe this document is fine.  There's no need for salting nor
iteration counts in a ZKPP like this (though an augmented version
would require salting, and preferably also iteration counts, so as to
slow down dictionary attacks on verifiers should the verifiers be
lost).

Nico
--

---

From: Glen Zorn <[email-masked]>
Date: Fri, 15 Apr 2011 09:10:52 +0700

>> We, secdir, should be encouraging wheel reuse wherever possible over

Shh!  You're questioning what may be the IETF's _real_ primary role:

> "We" never have encouraged that. Many of "us" are chairs of WGs whose charters explicitly allow or mandate the opposite of what you are proposing. If you want a change, it has to come from the ADs,…

Reinventing the wheel 'r' us!

---

From: Dennis Kügler <[email-masked]>
Date: Thu, 14 Apr 2011 18:39:13 +0200

Nico,

Dennis