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

[Yaron Sheffer <[e-mail]>]

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