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

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 22:31:19 -0400 (EDT)

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Mar 2015 09:45:53 -0400

> SubjectPublicKeyInfo that encodes the algorithm in the SPKI value

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.

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

    > 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Wouters <[email-masked]>
Date: Fri, 20 Mar 2015 14:51:28 -0400 (EDT)

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

> saying that a new IPSECKEY would juse use this registery for the algorithm

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

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

> 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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Mar 2015 20:03:00 -0400

> of valid algorithm numbers once we allow any kind of SPKI.

Sure, that makes sense, but wasn't the point of punting it all to
SubjectPublicKeyInfo, because if you are going to do new assymetric
algorithms, you are going to have to define how the signature works, and so
specify that part anyway?

    > IPSECKEY had to have its own registry.

I'd say that the IKEv1 registry wasn't easy to reference, IANA was kinda a
mess on those days, and IKEv2 was coming soon...  In hindsight, it should
have referenced something else.  Also the IPSECKEY was the first RR that went
through in what was supposed to be the "easier" RR approval process, and I
think that any additional references would have scared the reviewers over
there.  

    > records. Who determines which ones are allowed and what are the

I think that ipsecme-oob-pubkey could add new items to the algorithm field,
which is defined as IETF Consensus.  I suggest adding one, which says that it

    > IKE_AUTH (and they possibly rejected yours)

We have that problem right now: one could have RSA or DSA RR.
How is this any different?  I think that IKEv2 has no requirement that the
two ends authenticate with the same algorithm.   I agree that this makes it
difficult to know which of many algorithms to use; I think the answer is
that CERTREQ payloads must be present.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 31 Mar 2015 13:04:54 +0300

> SubjectPublicKeyInfo that encodes the algorithm in the SPKI value

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
> 

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.

> wait and see if we will replace IPSECKEY anyway?

Which registry is two octet value?

Now I am really confused...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Mar 2015 11:34:39 -0400 (EDT)

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

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

> the key other end sends to you.

It has the same problem.

> (14) methods. I do not think we need separate authentication method

Bare public keys could be algorithm FOO once you parse their ASN.1. Are
you saying that we will only ever support SPKI's of known IKE
algorithms? 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? 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.

> Now I am really confused...

This is two octets:

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

This is one octet:

And ipseckey uses one octet:

https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml#ipseckey-rr-parameters-1

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

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.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 31 Mar 2015 20:12:39 +0300

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

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

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

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

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

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

> 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.
-- 
[email-masked]