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

Yaron Sheffer <> Thu, 14 April 2011 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A671E08D2 for <>; Thu, 14 Apr 2011 09:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SsgewyrV0Qee for <>; Thu, 14 Apr 2011 09:52:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 02A48E08D5 for <>; Thu, 14 Apr 2011 09:52:10 -0700 (PDT)
Received: by wwa36 with SMTP id 36so1509517wwa.13 for <>; Thu, 14 Apr 2011 09:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zUrt3E/4IcIaHOlPmV2PHUzRCmkoGkp+at9184iHd/g=; b=kbo36N2uX6SzbqGtsNgiLsuRyjcXg+9BM0Kz08Z1dMq+dZq7vB97ZokhotQNBQ6yj9 20qZB3fHhiA6AlyXlotDr8rZnqcPOdaqFAedz+iv9KyPk82PX5ga2Vcb/i5VcRO4+ZOB qQvifO5c19EPk9w2XKJc8jCjv0ggssKEv8pmc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZX9qHiFbscPpzyO0m/z+wD/5sTNg58tzdCdwF1occTQjwdtMNa5anQXdg9TlsaCOd7 LkEz/09OQegJsT2lSaGdHFbbSXKtQc8furzRKt7U+1OUvigSfgZN9t4QEJNCFe2yBc7x KEem0WN1OH4OejViHkY4ubmswXsyRw3sXvFnM=
Received: by with SMTP id p72mr2191320wej.26.1302799883817; Thu, 14 Apr 2011 09:51:23 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id p5sm1110347wbg.45.2011. (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 09:51:22 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Apr 2011 19:51:17 +0300
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Nico Williams <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Apr 2011 16:52:12 -0000

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.


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