Re: [IPsec] RFC4869 bis submitted

Bill Sommerfeld <sommerfeld@sun.com> Thu, 19 November 2009 23:45 UTC

Return-Path: <sommerfeld@sun.com>
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 1F8D13A698F for <ipsec@core3.amsl.com>; Thu, 19 Nov 2009 15:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 o37zi4KIl2Cx for <ipsec@core3.amsl.com>; Thu, 19 Nov 2009 15:45:46 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 47C8F3A68C1 for <ipsec@ietf.org>; Thu, 19 Nov 2009 15:45:46 -0800 (PST)
Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAJNjeNE012431; Thu, 19 Nov 2009 23:45:40 GMT
Received: from thunk-west.local (dhcp-mpk17-108-155.SFBay.Sun.COM [129.146.108.155]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAJNjcqg027412; Thu, 19 Nov 2009 15:45:38 -0800 (PST)
Received: from thunk-west.local (thunk-west [127.0.0.1]) by thunk-west.local (8.14.3+Sun/8.14.3) with ESMTP id nAJNjYr0016400; Thu, 19 Nov 2009 15:45:34 -0800 (PST)
Received: (from sommerfeld@localhost) by thunk-west.local (8.14.3+Sun/8.14.3/Submit) id nAJNjYnj016399; Thu, 19 Nov 2009 15:45:34 -0800 (PST)
X-Authentication-Warning: thunk-west.local: sommerfeld set sender to sommerfeld@sun.com using -f
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p06240828c72b7fc0c3ce@[10.20.30.158]>
References: <D22B261D1FA3CD48B0414DF484E43D3211B49B@celebration.infosec.tycho.ncsc.mil> <1258667497.15596.206.camel@thunk-west> <p06240828c72b7fc0c3ce@[10.20.30.158]>
Content-Type: text/plain; charset="ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Nov 2009 15:45:34 -0800
Message-ID: <1258674334.15596.312.camel@thunk-west>
Mime-Version: 1.0
Cc: ipsec@ietf.org, "Law, Laurie" <lelaw@tycho.ncsc.mil>
Subject: Re: [IPsec] RFC4869 bis submitted
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: Thu, 19 Nov 2009 23:45:47 -0000

On Thu, 2009-11-19 at 15:08 -0800, Paul Hoffman wrote:
> The text says:
>   IKEv1 implementations MUST
>   support pre-shared key authentication [RFC2409] for interoperability.
>   The authentication method used with IKEv1 MUST be either pre-shared
>   key [RFC2409] or ECDSA-256 [RFC4754].
> To me, that sounds like preshared keys are just fine for IKEv1 in this
> profile, but I might be misunderstanding what you mean by "usefully".

I make a distinction between "optional to use" and "optional to
implement".  There are many things which are optional to use but
effectively mandatory to implement -- an implementation is not viewed as
complete unless it allows the use of the option.

As you pointed out earlier in this thread, this profile is an individual
submission describing a particular organization's requirements.  I'm
reluctant to guess or rely on the guess of someone who isn't part of
this organization when the document itself could be clarified.

> >As a practical matter, the ECDSA piece of this spec is likely to be the
> >largest and last piece built -- given a working elliptic curve codebase,
> >plugging ephemeral ECDH into an IKE implementation is a much smaller
> >problem than building ECDSA into both an IKE implementation and the PKI
> >client codebase, tools, and keystores it relies on.
> 
> Probably true, but ECDSA is far from impossible, as the OpenSSL people
> have shown for a while now.

There is a large gap between "can deliver next week" and "impossible".
(I'll also note in passing that changing which PKI client codebase you
use in an IKE implementation is also a sizeable task).

					- Bill