IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 20 March 2015 13:45 UTC

Return-Path: <mcr@sandelman.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 325191B2D6D for <ipsec@ietfa.amsl.com>; Fri, 20 Mar 2015 06:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 ooZdBCL8q_CH for <ipsec@ietfa.amsl.com>; Fri, 20 Mar 2015 06:45:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BF91B2D6A for <ipsec@ietf.org>; Fri, 20 Mar 2015 06:45:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F91E203C6; Fri, 20 Mar 2015 09:55:30 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 55E0D63B76; Fri, 20 Mar 2015 09:45:53 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 40CAC63731; Fri, 20 Mar 2015 09:45:53 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <alpine.LFD.2.10.1503092223260.27452@bofh.nohats.ca>
References: <alpine.LFD.2.10.1503092223260.27452@bofh.nohats.ca>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Fri, 20 Mar 2015 09:45:53 -0400
Message-ID: <5250.1426859153@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/M4Vd5jbqvQDeM6epjEgF-THVpRk>
Cc: Paul Wouters <paul@nohats.ca>, 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 13:45:57 -0000

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 agree that the algorithm number in IPSECKEY is significantly lacking.

    > 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?

    > 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.

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.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email