On Fri, 20 Mar 2015, Michael Richardson wrote:
Paul Wouters <[email protected]> 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 understand, but even for IKEv2 there will be no all knowing registry
of valid algorithm numbers once we allow any kind of SPKI.
> 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?
I'm saying we can't specify an algorithm number for all the possible SPKI's.
> 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.
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?
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.
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
