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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> 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.

I am missing what is the issue here.

When you get public key inside the IKEv2 in raw form, you extract the
key from there (i.e. decode the ASN.1 and get the key out in internal
public key representation). Then you fetch the key from IPSECKEY
records and do the same, i.e. again parse the key from DNS record to
the internal public key representation. Now you have two public keys,
and after that you simply compare them, and thats it. If they match
you know that the key used in IKE is same than in DNS.

Another use is that you fetch the public key for the other end
directly from the IPSECKEY DNS records, and use it, i.e. you ignore
the key other end sends to you.

> 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 :)

The keys in IPSECKEY are either DSA or RSA keys, and you can use those
in authentication either by using RSA(1), DSA(3) or Digital Signature
(14) methods. I do not think we need separate authentication method
for it.

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

Which registry is two octet value?

Now I am really confused...
-- 
[e-mail]