IETF Logo Mail Archive

[IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey)

Paul Wouters <paul@nohats.ca> Tue, 10 March 2015 02:31 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3E71A00BD for <ipsec@ietfa.amsl.com>; Mon, 9 Mar 2015 19:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAz5v9CSTCrz for <ipsec@ietfa.amsl.com>; Mon, 9 Mar 2015 19:31:29 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA5D1A00CF for <ipsec@ietf.org>; Mon, 9 Mar 2015 19:31:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l1L5T1fmqz8d; Tue, 10 Mar 2015 03:31:25 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=c6QO/i8i; dkim-adsp=pass
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id i5adUAbZdlKc; Tue, 10 Mar 2015 03:31:22 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Mar 2015 03:31:22 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B55FC82A1E; Mon, 9 Mar 2015 22:31:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425954681; bh=No/5k2Emy4mGnF+qjMo/2kPq0oF/ccSlc8x3lfWiUwQ=; h=Date:From:To:cc:Subject; b=c6QO/i8iUq1cAfjZ0Lb39ADVkwKUKujOTVNCiez45OeLEwRMi4XiSDXq53mdHaNNS ugDGEQsNUzwGaPVk1PmkaebyyKEnPLs9KnQKlJ3CDEvy8eEbl7otMfhhwzzDKzK+sR 1ApvPFwTmC6ro45Vy5oKH6D2VTYegpsEq7jsH7Tw=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2A2VKZv007309; Mon, 9 Mar 2015 22:31:21 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 09 Mar 2015 22:31:19 -0400
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
Message-ID: <alpine.LFD.2.10.1503092223260.27452@bofh.nohats.ca>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/MJfQcOwiL6pEXPrIIwLTD56Tej0>
Cc: Tero Kivinen <kivinen@iki.fi>
Subject: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 10 Mar 2015 02:31:31 -0000

I was looking at the interaction of draft-kivinen-ipsecme-oob-pubkey and
IPSECKEY, since IPSECKEY has an algorithm number but oob-pubkey uses the
SubjectPublicKeyInfo that encodes the algorithm in the SPKI value
itself.

So first, if we were to fix this for IPSECKEY (and I'm not yet convinced
we are there yet, as we might end up with updating IPSECKEY due to other
issues we'll find over the next few months) we might consider allocating a special
algorithm number to signify this in the IKE Authentication Method registry at

http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

For instance, 255 :)

Then I noticed that in fact the registry is a two octet value, while in
the IPSECKEY record this is a one octet value:

https://tools.ietf.org/html/rfc4025#section-2.1

That's clearly a bug. Is it worth filing an ERRATA for this or should we
wait and see if we will replace IPSECKEY anyway?

Paul

v2.23.0 | Report a Bug | By Email