Re: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt

Yaron Sheffer <> Sun, 21 March 2010 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 849AA3A6AD7 for <>; Sun, 21 Mar 2010 16:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FZPVEmzIv89j for <>; Sun, 21 Mar 2010 16:06:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B1723A6956 for <>; Sun, 21 Mar 2010 16:06:22 -0700 (PDT)
Received: by with SMTP id d23so253850fga.13 for <>; Sun, 21 Mar 2010 16:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YxKU7TieLMiEKAF6Szdpfk0d+622ecVWetg2zpEdH90=; b=soZEo9hkjYhUW3/8D9wW/SmnxsKno8N8yroC2B5aGaZS2MZl9pTvSig5V5kiaA1iJ+ 4BCaouWoutisu5qqDTfxJ5rtFaLK/1O499GHENI7OCxL5uQWjVtQcJzlZewLWqBHwVo8 VJsnp15ePaJNyzGpeaG+ittJrL1KXe7Ssb2sM=
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=WSBUB834pb7Ci8w5MEoPOWh6MAcJHRusn9ql+mzG04XnUMXfUxch5WXxoKuwauPDyH mjYfExIA7iOHLSBwCOLI5p0hmdfdbPb9GLAv/v7SpPXCVBbTSFbXsCfPYUE/Lp/ufi6j Jc8B9L8dg30lAdSN4It3qVR5RDc4babavmTEo=
Received: by with SMTP id d13mr1245535fgi.29.1269212795759; Sun, 21 Mar 2010 16:06:35 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id e3sm4134485fga.24.2010. (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 16:06:35 -0700 (PDT)
Message-ID: <>
Date: Mon, 22 Mar 2010 01:06:52 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Tero Kivinen <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Mar 2010 23:06:23 -0000

Hi Tero,

thanks for your comments. Please note that some of them have already 
been addressed in -01, which at the moment is only available on

While not disputing the importance of the engineering criteria, I think 
there's quite a bit of differentiation between the various options on 
security and IPR.


On 22.3.2010 0:20, Tero Kivinen wrote:
> The document should list more of the engineering considerations too in
> addition to the IPR and security. The Security requirement is
> mandatory (how that is show is completely different matter). The IPR
> issue would be nice to have. So I expect we end up looking other
> properties too.
> The other considerations section is quite short, and for example I do
> not really care whether the protocol was specified in standards
> document or scientific paper, as in any case we are going to make sure
> our document describes the protocol in a way that alows
> interoperability. Also in some cases the standards document are WAY
> too hard to read to be able to provide interoperability... :-)
> Also the second point of having protocol already integrated into IKE
> does not really matter, as the only thing it does is to save us some
> time. If the protocol is good and suitable to be integrated to IKE, I
> do not really think we should leave it out just because someone has
> not yet done the work to actually write the document telling how they
> are integrated. This is the document we are going to be writing here
> anyways. More suitable criteria would be to say it must be something
> that can be easily integrated to the IKE.
> I think this section should also include more concrete engineering
> criteria lists, like:
>    - Number of round trips
>    - Cost of cryptographic processing
>    - Does it share same cryptograhic blocks already used in IKE (I.e.
>      it would be better to have protocol using MODP+SHA1, than some
>      polynominal shares plush some hash function not used in IKE).
>    - Does it share for example the Diffie-Hellman groups already used
>      in the IKE.
>    - Does it fit to the IKE PSK model (i.e for example it should not
>      rely on trusted third party)
> Most likely we are going to be using those engineering criteria to
> select the final protocol, as I do not expect there be that much
> difference (that we can agree on) on other security and IPR.