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

Dennis Kügler <> Thu, 14 April 2011 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2758E079C for <>; Thu, 14 Apr 2011 09:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.948
X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d0PiZMQI4siZ for <>; Thu, 14 Apr 2011 09:39:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ECC1EE0716 for <>; Thu, 14 Apr 2011 09:39:37 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id p3EGdVBL007429; Thu, 14 Apr 2011 18:39:31 +0200 (CEST)
Received: (from localhost) by (MSCAN) id 5/; Thu Apr 14 18:39:31 2011
X-P350-Id: 6d3919f233c3d5e0
X-Virus-Scanned: by amavisd-new at
From: Dennis Kügler <>
Organization: BSI Bonn
To: Nico Williams <>
Date: Thu, 14 Apr 2011 18:39:13 +0200
User-Agent: KMail/1.9.10 (enterprise35 20110321.6842210)
References: <> <> <>
In-Reply-To: <>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <>
X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE:; VDF:; host:; id=24706-Ta81yY
X-Mailman-Approved-At: Tue, 19 Apr 2011 10:19:34 -0700
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 16:39:40 -0000


> PACE does not use a standard PBKDF.  That's not necessarily a problem,
> of course, but it could be.  There's no iteration count, for example,
> in the SPwd nor KPwd derivations (an iteration count belongs in the
> SPwd derivation, if anything).  Nor is there any password salting(!),
> nor any discussion regarding the absence of salting.  The lack of
> salting should be considered fatal, IMO.  The lack of an iteration
> count is less significant, but I'd still rather see an iteration
> count.  Note that negotiating a salt and iteration count requires an
> extra round-trip.  And note that iteration count negotiation has
> security considerations.

"Standard" PBKDF are used to artifically enhance the entopy of the password, 
because low-entropy passwords are easy targets for dictionary attacks. PACE 
is a cryptographic protocol that is designed to (mathematically) withstand 
(passive) dictionary attacks independent of the strength of the password and 
therefore there is no need for additional countermeasures like salting the 

> Of course, PACE is targeting Experimental... do we care about
> cryptographic issues in Experimental RFCs?  I'd say we should, though
> less so than for Standards Track RFCs since we can only spare so much
> energy.
> I'm rather disappointed to see this wheel reinvented.  SCRAM (RFC5802)
> would fit right in instead of PACE, for example, and has the same
> kinds of properties as PACE, but with a number of advantages over PACE
> (SCRAM is on the Standards Track, received much more review, uses a
> PBKDF with salt and iteration count, is implemented, is reusable in
> many contexts, does channel binding, there's an LDAP schema for
> storing SCRAM password verifiers, ...).

Actually, the protocols have very different properties. SCRAM (more or less) 
requires a public key infrastucture in place, while PACE provides an 
authenticated and encrypted channel without any additional security layer.

> We, secdir, should be encouraging wheel reuse wherever possible over
> wheel reinvention.

Once you decide to abandon those simple and insecure password-based 
challenge/response protocols, feel free to make use of PACE instead of 
reinventing the wheel :-)