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

Yaron Sheffer <> Thu, 14 April 2011 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17995E08B8 for <>; Thu, 14 Apr 2011 11:25:54 -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 FMqG0g6ey0ny for <>; Thu, 14 Apr 2011 11:25:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5C386E084C for <>; Thu, 14 Apr 2011 11:25:48 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1848290wyb.31 for <>; Thu, 14 Apr 2011 11:25:47 -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=iBwzTkRu8/tvhrzsfL9xIMxQNpfO9X86HQHtuaBie2I=; b=mZeQjeaGxFKEliGqkIuVOWjUfuLADrzJdRCLh+ROI+MA4jVyhX/LlUUG6RJq4E8NWd dOiqi54QE6wbU7iC/XBjMnIPsMTWwyhti4KsYfDBBMXJYQ2pT4RoglDdSRTi8fPCxweF fVME8Jomo0lRDEJe54fvd/QKi/IVOKWK5e3Ec=
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=DWe4+N/lA1S4pFMT/f94/wT7WkiShBDq36IPrBPB/OcjBZiEcrHJskOqWsi2mc0+46 gEI/bqnutDy1b7GYXSfFAJU87DcwCTB1eSLufoXzpb/n8MRAJH45RlgZZrS4Nywyc79N nXQEp5C+ZFvmK4BsFWaDuEGyN7RpfSDexn6WQ=
Received: by with SMTP id bh5mr173412wbb.155.1302805547650; Thu, 14 Apr 2011 11:25:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id h11sm1155980wbc.60.2011. (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 11:25:47 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Apr 2011 21:25:42 +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 18:25:54 -0000

Hi Nico,

ENONCE in and of itself is not vulnerable to an off-line dictionary 
attack because the password encrypts a random bit string, and we take 
care that there is no stray entropy (padding, MAC) that such an attacker 
could use.

As to the bigger question of why the protocol as a whole is not 
vulnerable to the attack, you will have to follow the proof in the paper 
(or maybe just ask my coauthor).

And regarding the usage scenario: the primary scenario is password-based 
machine-to-machine authentication. Yes, sysadmins are human (in most 
cases :-) and they tend to use short passwords for machine auth, much 
more often than we would have liked.

There is a secondary use case that's the usual human-to-server auth, 
where the peers are too lazy to use EAP. I'm questioning whether this 
scenario is interesting enough to add a salted "mode" into the protocol.


On 04/14/2011 08:59 PM, Nico Williams wrote:
> 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
> authentication.
> 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
> users)?
> Nico
> --