Subject: Re: [sidr] preventing SKI collisions

From: Stephen Kent <[email-masked]>
Date: Mon, 01 Jun 2015 17:03:18 -0400

Richard,

Thanks for thinking (in great depth) about the potential security 
implications of
SKI collisions in BGPsec.

In the general case of a PKI, collisions of SKI values are not security 
relevant.
The SKI MAY be used in path discovery, but the intent was to limit its 
use to
quickly finding the right CA cert when multiple CA certs appear in the same
directory entry.  (Specifically, one looks at the directory entry for the CA
specified as the Issuer of the cert for which a path is being 
constructed. if
there is more than one CA cert in that entry, one can compare the AKI in the
target cert against the SKI values in each of the candidate parent CA certs.
The alternative is to try verifying the signature on the target cert 
using each of the
public keys in the candidate parent certs. So, SKI/AKI matching is an 
optional
optimization.) In the RPKI (ignoring BGPsec for the moment) this is still
how the SKI is to be used, and thus the only problem that might arise if an
INR holder created a lot of (CA) certs with the same SKI value (but 
different keys)
is that the optimization would fail, and the RP would have to revert to the
"check the signature with each public key" fallback.

In BGPsec, the signature block carries an SKI and that value is used to 
search for the
right key to use when verifying the signature on a signature segment. 
Each signature
segment aligns with a secure path segment entry. The validation 
algorithm described in
Section 5.2 of te BGPsec spec says that one queries a router cert 
database containing
triples of (ASN, SKI, public key). Each query uses the ASN as the first 
lookup key, then
it uses the SKI to locate the right key, if there is more than one for 
the AS. This
is analogous to how the SKI is used in a traditional PKI, i.e., the SKI 
is used to
speed up the process in case there are multiple public keys for the same 
AS. (The algorithm
is not quite the same here, because an SKI match is required, but the 
security
implications are the same.) Thus, while there is no need for SKIs to be 
globally
unique, SKI collisions for router certs for a single AS could degrade 
the router cert
lookup process.

Since we want a router to be able to quickly locate the right cert, it 
does behoove
us to avoid the potential attack you noted. There is no easy way to 
change the SKI
computation algorithm in a cert and signal that to RPs. This is an 
oversight in the
X.509 design, but one that does not seem especially problematic in the 
normal PKI
context. So mandating use of a different hash alg for SKI/AKI 
computation is not
very attractive. In the BGPsec/RPKI our environment we could impose a 
requirement
on RPs  to check router certs to verify the criteria you cited, i.e., no 
two router
certs for the same AS# are allowed have the same SKI and different 
public keys.
I think this is a simple, additional check to add to the router cert 
profile I-D.

Thanks for paying such careful attention to this!

Steve