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

Tero Kivinen <kivinen@iki.fi> Sun, 21 March 2010 22:20 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C09BF3A6956 for <ipsec@core3.amsl.com>; Sun, 21 Mar 2010 15:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=-1.710, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6NCF3yXPScUv for <ipsec@core3.amsl.com>; Sun, 21 Mar 2010 15:20:38 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) by core3.amsl.com (Postfix) with ESMTP id C4D343A677D for <ipsec@ietf.org>; Sun, 21 Mar 2010 15:20:23 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o2LMKZ2K023927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 00:20:35 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2LMKZqp027407; Mon, 22 Mar 2010 00:20:35 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19366.39859.336431.204705@fireball.kivinen.iki.fi>
Date: Mon, 22 Mar 2010 00:20:35 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org, yaronf@checkpoint.com
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 14 min
Subject: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Mar 2010 22:20:41 -0000

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.