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

[Michael Richardson <[e-mail]>]

Paul Wouters <[e-mail]> wrote:
    >> Paul Wouters <[e-mail]> 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.

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?

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

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.  

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

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
comes in SubjectPublicKeyInfo format:

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

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-