It boils down to what is the meaning & utility of IPSec policy specifying roots or credentials to use.
IPSec implementations typically do two things -
1. configure a specific end-entity cert to use, and/or
2. configure a root which:
a. is the root of a credential you will offer and/or
b. is the root to include in CRPs sent to the peer
The PKI certificate store can be configured two ways:
1. trust the peer's root, either for all purposes or a specific purpose (e.g. IPSec)
2. don't trust the peer's root, but an admin can cross certify the peer's root for all purpose or a specific purpose (e.g. IPSec).
My first point in the comment below was that your local IPSec policy config tells you what roots & certs to use. So the fact that I get a CRP from the peer helps me chose the right cert if I am allowed to use several which may be under different roots. But the CRP must not contain the only root from which I am required to provide an end-entity cert.
The second point is that I shouldn't have to know what root to request from the peer. This is to enable IPSec to work in the cases where PKI cross-certification never establishes a common root that IKE could negotiate in CRPs, but does establish PKI trust for specific purposes which IKE should be able to use to successfully authenticate. The IPSec policy shouldn't have to fully duplicate the PKI trust policy - as IKE is just a vehicle to exchange identities which in the end are validated by the receivers PKI rules & store configuration.
If you receive a CRP and MUST supply a credential that matches that CRP - then it mandates the policy configuration on the other side so that it "knows" the right root DN to send which matches the client's cert issuer root. It is unnecessary to know a-priori in IPSec policy which root DN to send - in one case above the peer should be able to and certainly can send the credential it's configured to use, regardless of CRPs received.
In the network model of PKI trust - where multiple roots exist, two systems have credentials from different roots, yet an admin can cross certify the other root, either for all purposes or for a specific purpose (e.g. IPSec). What comes out of this admin action is a "cross-certification certificate" - which may not even be stored on your local system - but stored in a directory some where.
Thus you don't have the peer's root in your IPSec policy because in fact you don't trust the root entirely - your policy says simply that you trust only your own root entirely.
But yet the peer's certificate will be valid if IKE calls the PKI library with because of the PKI chaining code finds the cross-cert & returns success.
A practical example - business to business
Company A's end-system clients have certs from Root A, and Company B's end-system servers have certs from Root B. So each IPSec policy is configured to use either the one end-entity cert that the machine has and/or send CRPs just for the one root. The clients & servers within each company can use the company's certificates for trusted IPSec communication.
Now Company A wants to give company B's systems access to Company A's DMZ servers. Clearly if the IPSec policy on every one of Company B's end-systems needed to change, so that it had to send a CRP to Company A servers to request Company A based certs, this would be difficult, if not impossible depending on the IPSec policy implementation. But assume it was possible, it's still not enough to make this scenario work. Company B systems PKI library would need to know how to validate Company A server end-entity certificates & vice versa. The PKI world provides the capability of Company B saying it trusts Root A for IPSec - this is a cross-cert between Root B & Root A. Likewise Company A says it trusts Root B for IPSec. So now B systems can validate A end-entity certs, and A's system can validate B's end-entity certs - but neither have a common root to negotiate. And they don't need one. Each side provides the end-entity cert it is configured to use, each side may send CRPs for it's own corresponding root. But when you receive a CRP containing a root which you a. don't have in your IPSec policy, b. don't have in your list of trusted roots, and c. don't have a cert from, you disregard the CRP and send your own cert and the receiver PKI can validate it.
-----Original Message-----
From: Jan Vilhuber [mailto:vilhuber@cisco.com]
Sent: Tuesday, September 26, 2000 4:51 PM
To: William Dixon
Cc: Tero Kivinen; Scott Fanning; IPsec List
Subject: RE: CERT_REQ_PAYLOAD usage
On Tue, 26 Sep 2000, William Dixon wrote:
> Tero, good ideas, one issue though:
>
> 4) When you receive certificate request you MUST send your own
> certificate for that CA.
>
> Your own IPSec policy typically includes what roots to use or what certs
> to send - so you have to enforce that, regardless of what the peer sends
> you. If the CRP's don't match the roots you are configured to use, then
> you are saying here you MUST fail. And that means that the peer MUST
> send a correct CRP for the credential you have - which of course isn't
> always possible.
>
Not sure I follow that: Why is this not possible? Common sense tells me that
I should send a CRP for ALL roots I know about (or all roots that I'm allowed
to use by some obscure local policy, or whatever). If you answer with the
ones that YOU have, we've got a non-empty intersection. If there's no
overlap, then the intersection IS empty, and we must fail, because we don't
share a root.
Is there something I'm missing?
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847