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

Yaron Sheffer <> Thu, 14 April 2011 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36D29E0712 for <>; Thu, 14 Apr 2011 12:46: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 Yq8f-QeUJa1h for <>; Thu, 14 Apr 2011 12:46:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 592A2E0687 for <>; Thu, 14 Apr 2011 12:46:53 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1909570wyb.31 for <>; Thu, 14 Apr 2011 12:46:52 -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=UeahZt0KHePx2uFuQOlyBlQ4rawEPY1/BPZtqJCzxEk=; b=f2Tk/Vs1Hy3qzkc8JVFgaMueJw2aZIyWBRnbPiYqaUCp/YfAQnE+tnuwZu1+pMhJ2a OD+g6ySFJgltRydHL6FrB1qUH/853SqgjHGlAx8s7VXNoRhY7qJSv3mgj9TOa8jGo5HF 1V6vkFnd0CCaHDA5o9KI/drYyGnCMBGF1PUFY=
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=BplY6domssUCDhIb8KZHIsxz78E2T69KoKVhrqnmfpZuLxoI9srwjlfvjsV7N+J6V2 p7Us34aBwdtKy98HkwU5tb4DqHIukoZtPh/0nTjgk4fXo+GsVwSR2MlWmfCcpZICGzMS kuChIdLr5r06vG7rHM0GSWWZLPi2q2u0MJTqA=
Received: by with SMTP id j7mr1208252wbz.60.1302810412685; Thu, 14 Apr 2011 12:46:52 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id bd8sm1194850wbb.31.2011. (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 12:46:52 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Apr 2011 22:46:50 +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 19:46:54 -0000

Yes, PACE is a ZKPP, and the AUTH payloads depend on values that the 
attacker cannot compute (PACESharedSecret). Again, this assertion is 
based on the mathematical proof of the protocol.

We have tried for many years to educate people to use better passwords. 
This has not worked. So we'd better assume that passwords are weak by 
default, and if they're good, all the better.


On 04/14/2011 09:44 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 1:25 PM, Yaron Sheffer<>  wrote:
>> 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.
> But the ENONCE paired with the AUTH payloads is subject to off-line
> dictionary attacks (the attacker will have to have impersonated the
> responder in order to obtain the necessary material).
>> 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).
> It sounds like you're asserting that PACE is a ZKPP.  Is that right?
>> 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.
> You might want to clarify this in the abstract and introduction then.
> But even so, as long as the passwords are human memorable and the
> mechanism is not a ZKPP, then my other comments stand.  However, if
> this is really for machine authentication then I'll be happy with text
> exhorting admins to pick good passwords.
>> 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.
> Fair enough.