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

[Dennis Kügler <[e-mail]>]

Nico,

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

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

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

Dennis