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

Nico Williams <> Thu, 14 April 2011 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FEB6E0765 for <>; Thu, 14 Apr 2011 10:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id onoctf8wJkN4 for <>; Thu, 14 Apr 2011 10:59:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 24BA7E065F for <>; Thu, 14 Apr 2011 10:59:40 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 8090267407B for <>; Thu, 14 Apr 2011 10:59:39 -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=uXVFaDS0v8XGl1lyFEBP5tsXRCNKtFAZwi+HtP2LOgvO DJSdkUfx+YzUsMYP9XR2l427biH070HBRJPLL1xBaJr6WanojKztCk2Yt8gBHo+I bRYq37KTgNnWNn6fYWWz6ki8e/xYXqbvX/MKEs9HL5qB/hubMliDrPX8XGas6cE=
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=qFcqmKuugEpU+1HADCa6Vdri2V0=; b=NpSXcl9dS8t 2nP4VMDa6U2QROFDPd0/qrVCKGQgHkNduoMLMEb+AtO6y6fwVOg/4OVadYFklGZS CDGLqVa8c5/UMcbImFDWCujoxhzaGq57eInQBImQqakSK2h8shdwBzq4zgqOUObi QqAXOs9OvYtjAxQ8BxgR3TmyFqSm7GKs=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 4DD20674074 for <>; Thu, 14 Apr 2011 10:59:39 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1889309vxg.31 for <>; Thu, 14 Apr 2011 10:59:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id eq8mr1473614vdc.214.1302803978724; Thu, 14 Apr 2011 10:59:38 -0700 (PDT)
Received: by with HTTP; Thu, 14 Apr 2011 10:59:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 14 Apr 2011 12:59:38 -0500
Message-ID: <>
From: Nico Williams <>
To: Dan Harkins <>
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 17:59:41 -0000

On Thu, Apr 14, 2011 at 12:47 PM, Dan Harkins <> wrote:
> On Thu, April 14, 2011 10:25 am, Nico Williams wrote:
>> 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.

I'm distinguishing secure from authenticated.  If the channel can
provide confidentiality and integrity protection then it's secure.  If
it's authenticated that's even better.

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

I don't see how the ENONCE in PACE is resistant to off-line dictionary
attacks.  What am I missing?

I stand by my assertion that SCRAM with channel binding to the KE
exchange, and protected by that KE exchange, is protected against
passive attacks, and if the channel is authenticated, then it's also
protected against active attacks.  (Note that I never proposed SCRAM
w/o CB, nor would I have.)

If I'm right that ENONCE is resistant to off-line dictionary attacks
then I stand by my assertion that SCRAM (with CB) is at least as
secure as PACE, and arguably more so.

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

I understand that PKIX credentials will not always be available for
either, much less both of the peers (if they are available for both
then the only thing the password adds is an additional authentication
factor, and is probably an undesirable complication).  However, I
expect that a certificate will often be available for "servers".  As
for SCRAM, again, _with_ CB it's no weaker than PACE.

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

If there's no user and the password is randomly generated then I have
no concerns whatever.

However, everything in the I-D leads me to believe that the password
is intended to be memorable to human users.  For example, why bother
with stringprep if the password is intended to be a randomly generated
string?  Why bother with Unicode at all in that case?  Moreover, the
introduction specifically refers to weak shared secrets, which leads
me to believe that PACE is specifically intended for user

So which is it?  Is PACE just an improved PSK mechanism?  Or is PACE a
password-based mechanism as we normally think of them (i.e., for human