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

[Nico Williams <[e-mail]>]

[Resend.  Forgot to reply-all.]

On Thu, Apr 14, 2011 at 2:04 AM, Yaron Sheffer <[e-mail]> wrote:
> 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.

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
--