[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Aggressive/Base Mode Signature Queries
Suppose you share CAs C1 and C2 with some peer B. C1 issues you a
certificate Cert(A1,C1) under the name A1, and C2 issues you a certificate
Cert(A2,C2) under the name A2, with A1 != A2. Similar B gets certificates
Cert(B1,C1) issued by C1 and Cert(B2,C2) issued by C2.
If you believe you share both CAs with B, then for aggressive mode you might
as well use either of your certificates to authenticate yourself, say the
cert issued by C1. So you send the first agressive mode message:
(1) HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ---->
Here the notation IDii(A1) denotes the initiator's ID payload conveying its
identity A1, and CertReq(C1) denotes the optional Certificate Request
payload requesting a certificate (chain) signed by C1.
There seems to be nothing in the protocol preventing the peer from
responding
(2) <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C2)
Here IDDrr(B1) denotes the peer's ID payload conveying its identity B1 taken
from the cert(B1,C1), Sig(B1) B's signatures using the private key
corresponding to Cert(B1,C1), and CertReq(C2) is a request for a certificate
from you signed by CA C2. B might make such a response, because its local
policy says that it should always authenticate initiating peers using
certificates issued by C2.
In the third message the protocol says you are supposed to send
(3) HDR, Sig(A2), Cert(A2,C2) ---->
This seems like a problem, because the name A2 from the certificate
Cert(A2,C2) does not match the name A1 from the ID payload IDii(A1) from
message (1). You'd think B would not want to accept such a message, as if A
can get dupe D into computing the signature Sig(D2) using certificate
Cert(D2,C2) for him, B would accept A as D:
HDR, Sig(D2), Cert(DA2,C2) ---->
Since the protocol does not seem to forbid (2) as a response to (1), it will
most certainly arise at some time. We can think of a number of potential
implementations to address this circumstance. For the responder, some
possibilites seem to be:
a. B could respond to (1) with (2), as above, or
b. B could decide that (1) is not really proper, because it is insisting
that initiating peers use certificates issued by C2. In that case, B would
respond with a Notify returning INVALID-CERT-AUTHORITY error, or it might
ignore (1) entirely.
c. B could decide that response (2) is wrong, and respond to (1) only with
(2') <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1)
or
(2'') <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C1)
where C1 is the CA from (1).
Alternative a does not appear to be a good idea, since it opened this can of
worms in the first place, but it is not precluded by the protocol spec.
Alternatives b and c both seem better and are not necessarily mutually
exclusive, but neither are required by the protocol in this situation, and
it is not evident that either allows full scope to local policy.
Some possibilities for the initiator are:
d. The initiator could respond as above by sending (3) in response to (2).
As indicated, we beleive many implementations will abort the negotiation at
this point because A2 != A1. Hence communications will not always be
possible with this course.
e. The initiator also might abandon the original negotiation on the receipt
of (2). Instead, it restarts the dialog with a new message
(1') HDR, SA, KE, Ni, IDii(A2), CertReq(C2) ---->
since B has expressed a preference for certificates issued by C2. This
should work, but it introduces a bit of computational overhead in the
responder for returning such a pig-headed response; people get what they pay
for. But what if the initiator's local policy might be to authenticate all
responders using CA C1 and never CA C2? Nope; wrong again.
f. The initiator could try to insert a new ID payload in its third message,
even though ISAKMP and IKE don't give us any reason to think this is
allowed:
(3') HDR, Sig(A2), IDii(A2), Cert(A2,C2) ---->
and we don't see why B would have any reason for accepting this, either,
since A1 != A2.
g. The initiator might try to circumvent the whole problem by sending
"duplicate" requests in (1):
(1'') HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ---->
HDR, SA, KE, Ni, IDii(A2), CertReq(C2) ---->
and then respond to the first response it receives.
It looks like any alternative the initiator pursues (at least any we've
thought of) is a bad idea.
Another possibility is to require every implementation supporting more than
one CA to provide policy parameters allowing the administrator to specify
which behavior(s) a-g to use in this circumstance. This does not appear to
be a winning strategy, in part because administrators could never figure out
how to set the parameters.
Yet another possibility is to try to eliminate the whole problem by
declaring this is a non-issue, because the initiator must be configured to
use the right certificate and that it should have sent
HDR, SA, KE, Ni, IDii(A2), CertReq(C1) ---->
instead of (1) to begin with. However, the specification does not mandate
this, either, and again requiring yet more configuration does not appear to
be a winning strategy for getting the world to adopt certificate-based
authentication and IPsec.
Yet another possibility is just not to support Agressive mode with digital
signatures.
Maybe there are other alternatives we've overlooked. Since we want our
implementation to interoperate with others, the question is how do other
implementations handle this situation? A similar question obtains for Base
mode.
-- Jesse Walker
Follow-Ups: