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

Yaron Sheffer <> Thu, 14 April 2011 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA763E06A4 for <>; Thu, 14 Apr 2011 10:24:07 -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 8HJ7XaM1gkxU for <>; Thu, 14 Apr 2011 10:24:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26C38E073F for <>; Thu, 14 Apr 2011 10:24:06 -0700 (PDT)
Received: by wwa36 with SMTP id 36so1533935wwa.13 for <>; Thu, 14 Apr 2011 10:24:05 -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=XFs2CI5AUYfoIFcWYcWQ90MeE5gaP0p2Xb1cS0b5vTY=; b=Q41vbiym7W6NST5E+4qSqGs3uG/EzTlA0EmS6yhibwNg8Yw3w2jz3PrBMw+w9c4PJ0 8y56OSSqaSvBgafw+0fA+20Fij8CrNQuzth4Isj3LYMip0yQfO+r1ChCTog0I6dC2PUU zIXkfb3p8bQZicgnOTNrP5Fxxkiice3KAWGBU=
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=JCwMXL1ta4MdQ3wN2zVwSmZS1fuOoHBE3foFd3l/TP0tk5llcLb8S+rmOpw3BXGMqc fqN4b1L3n3HnrCutoRO4qYcMD4bt9iW1BwRf0l57kIr2jH/lc/k5TyIlH6K/qJ17pqPf BKwPve2WzIiqMs33uZ9qEHN0WAvhECpMJipDs=
Received: by with SMTP id ep7mr1087379wbb.40.1302801845397; Thu, 14 Apr 2011 10:24:05 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id p5sm1126612wbg.62.2011. (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 10:24:04 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Apr 2011 20:24:00 +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 17:24:07 -0000

I am unfamiliar with SCRAM, and never claimed otherwise. I just quoted 
your own analysis during the ipsec ML discussion. *Still* not having 
read the documents, I'd like to remind you that any auth protocol over 
IKE is vulnerable to passive attackers until authentication is complete, 
channel binding or not.

We can apply random salt, not just salt with the user name, because the 
PACE "action" only starts at the *second* exchange of IKEv2. So we can 
piggyback a salt payload along with the Responder's notification that it 
supports the protocol.


On 04/14/2011 07:57 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer<>  wrote:
>> I'm amazed at the comparison of PACE with SCRAM. In a previous mail you
>> pointed out yourself that SCRAM is vulnerable to on-the-wire dictionary
>> attacks, which PACE is not. The IETF had never managed to standardize any
>> ZKPP methods until just recently (with the exception of TLS-SRP), and
>> finally we're doing something about it, even if on the Experimental track. I
>> believe this counts as a positive contribution to the security of the
>> Internet.
> 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.
> If you do not understand what I just wrote then you need to read RFCs
> 5056, 5929, and 5802 -- in that order.
>> I agree that salting the stored password (SPwd) would have improved the
>> security of this protocol (unlike iteration counts). And it can be added
>> with no extra round trips, since it's not "negotiated", just sent by the
>> responder. My coauthor and I need to consider the benefits vs. costs, since
>> the major use case here is not open servers, more often it would be VPN
>> gateways.
> Salting with a username requires no negotiation, but then you can't
> rename users without also changing their passwords (a minor issue).
> Nico
> --