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

"Dan Harkins" <> Thu, 14 April 2011 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 409E4E06CD for <>; Thu, 14 Apr 2011 10:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HiwDb0PzZ68t for <>; Thu, 14 Apr 2011 10:47:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3610AE0690 for <>; Thu, 14 Apr 2011 10:47:52 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id B1D211022404C; Thu, 14 Apr 2011 10:47:51 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 14 Apr 2011 10:47:51 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 14 Apr 2011 10:47:51 -0700
From: Dan Harkins <>
To: Nico Williams <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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 17:47:53 -0000

  Hi Nico,

On Thu, April 14, 2011 10:25 am, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 12:21 PM, Dan Harkins <> wrote:
>> On Thu, April 14, 2011 9:57 am, Nico Williams wrote:
>>> This betrays a fundamental misunderstanding of SCRAM and channel
>>> binding.
>>> SCRAM with channel binding to a secure channel is as secure as PACE,
>>> and arguably more so.
>>  PACE does not require a secure channel to be passed through. In fact,
>> the way it's used there is no security (yet), it's just an
>> unauthenticated
>> Diffie-Hellman that "protects" the channel that PACE is done through.
>> PACE performs authentication of the IKE SA by doing a ZKPP and adding
>> the
>> authenticated and shared secret result of the ZKPP into the result of
>> the
>> unauthenticated Diffie-Hellman (plus assorted cruft).
> In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a
> "channel".
> There seems to be a terminology disconnect.  As a result of this
> disconnect you and others are discarding the work of others (e.g.,
> SCRAM in this case) without understanding it in the first place.

  I don't think there's a terminology disconnect. Yes, it's a "channel",
but the important thing is it's not a "secure channel", which is what
you said above.

  SCRAM is not resistant to off-line dictionary attack, PACE is. So
the work of others has not just been ignorantly discarded, it is just
not appropriate to use in this particular case.

  What is needed here is to parlay a low-entropy password into a
secure secret without anything else. There is no way to "authenticate
the responder with PKIK" (as you implied in another email) because
there is nothing else that could be used in accordance with any PKIK RFC.
Using SCRAM here would be more secure than the broken PSK mode of IKE(v2)
today but would not be resistant to off-line dictionary attack.

  Don't think of this as a username/password protocol. There is no
real "user". There is just a password and the two side have to prove
to each other they know it without leaking any information about it
to each other or an adversary. SCRAM isn't the right tool for this job.