[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [83.145.195.1]) 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 [127.0.0.1]) 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. -- kivinen@iki.fi
- [IPsec] Some comments to the draft-sheffer-ipsecm… Tero Kivinen
- Re: [IPsec] Some comments to the draft-sheffer-ip… Yaron Sheffer