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

[Nico Williams <[e-mail]>]

On Thu, Apr 14, 2011 at 11:39 AM, Dennis Kügler
<[e-mail]> wrote:
>> 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.
>
> "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.

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

>> We, secdir, should be encouraging wheel reuse wherever possible over
>> wheel reinvention.
>
> 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
--