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

Nico Williams <> Thu, 14 April 2011 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DD1AE0800 for <>; Thu, 14 Apr 2011 09:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_11=1, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id La4W7TOEt0Nh for <>; Thu, 14 Apr 2011 09:54:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 87519E078C for <>; Thu, 14 Apr 2011 09:54:21 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id A68D5B8058 for <>; Thu, 14 Apr 2011 09:54:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s=; b=gWQMtzQZWvK7eAD5kWGJeZo9qDRdTt9FDjlHdmdS0W/Z s8oKq7GqzMWvYEOgjbw+UoAwphhEyRZafj3SBSB752LejrARB4IZrejWV6ZglR42 yT5awPUqgejlQie4MYoMVT8R8VxQthF/8NipGYR+kReF+g0kUI7BGujOSeVvNc0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=XcCAj7momQ+W+wtq4JeXamP/hJA=; b=RNkOgva2N3r QP7oJP5VKxgVZD8xFsA/sZ35RJNtVmqftmsjCqCaQOAA6GXXbd9OzJ8f+GrgCY6V C++a/ZwKrtB5xX/BHz1QZeYfAKbA0li88kumOlhmFCRzj5Jiir09Dj64ZcrHfzyi YUHA35pFeyQty9VWGnyxkeO3AueglF1s=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 7331BB8056 for <>; Thu, 14 Apr 2011 09:54:20 -0700 (PDT)
Received: by vws12 with SMTP id 12so1840139vws.31 for <>; Thu, 14 Apr 2011 09:54:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id io5mr1405656vdb.94.1302800059876; Thu, 14 Apr 2011 09:54:19 -0700 (PDT)
Received: by with HTTP; Thu, 14 Apr 2011 09:54:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 14 Apr 2011 11:54:19 -0500
Message-ID: <>
From: Nico Williams <>
To: Dennis Kügler <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:54:22 -0000

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