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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> On Tue, 31 Mar 2015, Tero Kivinen wrote:
> 
> > 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.
> 
> What if you get RSA keys but the IPSECKEY algo number was DSA?

Then you make sure you get all IPSECKEY records, and see if you find
RSA key too. If not, the key is wrong, and does not validate. 

> The problem is that the approach you describe is required for
> supporting bare public keys in IKE, but we have no algorithm
> identifier for that to put in the IPSECKEY record. Hence my
> suggestion for 255 or something for this case, which would mean "the
> algorithm as derived from the SPBI".

Which algorthm you are not talking about? The one in the certificate
payload i.e. the oob-key, or the one in the authentication payload?

When you put the IPSECKEY record out having the key, you do know which
type it has, and set the identififer in the IPSECKEY record
accordingly. When you are fetching the IPSECKEY record for the remote
peer, you get all the records you find, and you might find two, one
for DSA and one for RSA. Then you pick the one other end used in his
AUTH payload, i.e. the one it sent inside the CERT payload (either as
raw public key, or self signed X.509 key, or hash and url etc). 

> > 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.
> 
> Bare public keys could be algorithm FOO once you parse their ASN.1.

Yes.

> Are you saying that we will only ever support SPKI's of known IKE
> algorithms?

It is very hard to implement algorithms that I do not know anything
about, so yes, my implementations only support for known algorithms...
To be able to use some key you need to implement the support for that
specific type, so if you only support RSA, and DSA keys then those are
the only SPKI formats you will ever support. 

> I thought part of the idea here was that people could do AUTH for
> different algorithms without IKE needing to assign an algorithm for
> each?

Yes you can do that using RFC7427, i.e. the "Digital Signature"
authentication method. This has nothing to do with raw public keys,
except that both of them use ASN.1 objects to tell the type of object
after them. 

> Like if someone wanted to use RSASSA-PSS instead of RSA-PKCS1-v1_5 ?
> In IKE you cannot specify the type of RSA key, but in SPKI you can.

RSASSA-PSS support was added to IKEv2 in RFC7427, and if you do not
implement that, you cannot use RSASSA-PSS in IKEv2.

> >> 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...
> 
> This is two octets:
> 
> http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-8

This is for IKEv1, it has been obsoleted, and is not in any use
anymore (I can always hope :-)

It does not have any relevance for IKEv2 or for IPSECKEY when using IKEv2.

> This is one octet:
> 
> http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

Yes, and that is for IKEv2.

In IKEv1 the authentication method was negotiated inside the SA
payloads and because it was using basic encoding it was 16-bit field.

In IKEv2 the authentication method is transmitted as a first byte of
the authentication payload, and as we assumed there will not be too
many of them, only one byte was used. 

> And ipseckey uses one octet:
> 
> https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml#ipseckey-rr-parameters-1

This is transmitted inside the DNS records, and does not have anything
to do with IKEv1 or IKEv2 authentication methods registries. This
gives the type of the key, as those others give types of
authentication method (for example pre-shared key).

> But as Michael pointed out, the algo value of IPSECKEY is its own
> registry and (for some odd reason probably to exclude PSK) does not just
> re-use the same value of the other registry.

Why should it reuse registry which has nothing to do with it. Public
key type and Authentication methods are completely different things. 

> And I guess it is missing a private use range to accomodate people
> using a a private value (eg 65001 in IKEv1 or 201 in IKEv2)

Private ranges do not work that well in public DNS... 

> As I said, I think we are looking at updating IPSECKEY anyway, so it is
> not a big problem, but I think we do need to take these issues into
> consideration when designing something new.

I assume the IPSECKEY would require update to define new key types for
elliptic curves, but as those all can already be used with the
"Digital Signature" authentication method (or the ECDSA with SHA-xxx
on the P-yyy curve methods), I do not think there is that much issues
with that.
-- 
[e-mail]