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

Paul Wouters <paul@nohats.ca> Fri, 20 March 2015 18:51 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 03A411A88B9 for <ipsec@ietfa.amsl.com>; Fri, 20 Mar 2015 11:51:37 -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 lKTn8Dofw0FC for <ipsec@ietfa.amsl.com>; Fri, 20 Mar 2015 11:51:34 -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 582AF1A8896 for <ipsec@ietf.org>; Fri, 20 Mar 2015 11:51:34 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l7vMl66Zpz79Q; Fri, 20 Mar 2015 19:51:31 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=gGsZzZnj
X-OPENPGPKEY: Message passed unmodified
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 jy6bdc01-9ws; Fri, 20 Mar 2015 19:51:29 +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; Fri, 20 Mar 2015 19:51:29 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D4C780416; Fri, 20 Mar 2015 14:51:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426877488; bh=Zy/d/hld2+frVWFEZEKQAXI4Ug25Vnao6MFAkny0mW0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gGsZzZnjpIABcL0HaXwkihynHcKZp6pq+u4HLqbPSD5KBGkOPjGtnPBE/hLVQd2OH cPS6GQgNuwGyM07MmHhSLnBM7NXY5huwctQMzoXjgrSITRLDTWjAuM90W5t6p58TOq 2SfNnezm1tc6DU0xvygEuyidHUu4MEvh4+JKBGvo=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2KIpS4L013270; Fri, 20 Mar 2015 14:51:28 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 20 Mar 2015 14:51:28 -0400
From: Paul Wouters <paul@nohats.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <5250.1426859153@sandelman.ca>
Message-ID: <alpine.LFD.2.10.1503201443170.8576@bofh.nohats.ca>
References: <alpine.LFD.2.10.1503092223260.27452@bofh.nohats.ca> <5250.1426859153@sandelman.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/clTf7q8eevk02EI8Zc6jYFvd8p4>
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [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: Fri, 20 Mar 2015 18:51:37 -0000

On Fri, 20 Mar 2015, Michael Richardson wrote:

> Paul Wouters <paul@nohats.ca> wrote:
>    > 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.
>
> IPSECKEY having been authored some significant time prior to IKEv2, otherwise
> it would have reused some IKEv2 registry for the algorithm number.

I understand, but even for IKEv2 there will be no all knowing registry
of valid algorithm numbers once we allow any kind of SPKI.

>    > 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 :)
>
> I don't really undersatnd what you are saying.  Are you saying that we need a
> special IKE Authentication Method that signifies to use IPSECKEY, or are you
> saying that a new IPSECKEY would juse use this registery for the algorithm
> number?

I'm saying we can't specify an algorithm number for all the possible SPKI's.

>    > 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?
>
> But, IPSECKEY doesn't use an IKEv2 parameter, it has it's own registry.
> What you write above seems to suggest that it somehow references the IKEv2
> registry.  Maybe I don't understand the email.

I guess you are right here. I thought it would map 1:1 to:

https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-8

I guess I wasn't around the IETF at this time so I'm not sure why
IPSECKEY had to have its own registry.

It still means you cannot use all IKE(v2) algorithms in IPSECKEY
records. Who determines which ones are allowed and what are the
selection criteria?

> If we were to do anything, I'd say that we should create IPSECKEY algorithm
> type 3, and say that it uses the same SubjectPublicKeyInfo minimal ASN.1
> encoding that oop-pubkey uses.

Except if you have multiple algorithms, you can no longer use the
IPSECKEY record to lookup which one to use. Does the remote want RSA or
ECDSA? Well it will take some SPKI but you won't know until you're in
IKE_AUTH (and they possibly rejected yours)

Paul