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?
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".
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.
It has the same problem.
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.
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.
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 one octet:
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
