|
Scott,
my comments on CRPs below, but before agreeing on CRPs, we really
should agree on end-entity certs. The result of the bakeoff was that
people didn't want to do that, even minimally which is really unfortunate.
Rodney's, Paul & Charles' draft tried to get some sanity defined, which
included at least in which exchanges CRPs were sent. Perhaps we can
weed out what is contentious and agree on a few things.
Unfortunately the IKE peers have no way to
indicate that they need more than one end-entity certificate, or to
indicate a particular type of cert or content in the end-entity cert.
There is also no way for the gateway to tell a client that it needs
extra non-identity based certs - like attribute certs for gateway
authorization.
The
convention I know is: simply send CRPs to request the peer send you back an
end-entity cert that chains to that root. You are not limited on what you can
send, send whatever CRP you want, including a CRPs for the same root twice,
and for a root that you yourself don't trust - the latter case is required
to support certificate validations when cross-certs have been
issued.
The
peer may reply by sending all certs that chain to 1 root if there are multiple
certs, the peer may send only 1 end-entity cert. The peer may
send one or all certs for each CRP providing they exist. And the peer
may send an end-entity cert that didn't chain to any of your CRP roots.
The only real limitation appears to be how much will fit into a UDP payload -
since there is a define place to send Certs in the ID payload - at least in IKE
Identity Protect Mode (Main Mode). Up to you if you want to create a UDP
packet big enough that it will fragment - so the FW's & routers doing port
filtering allowing only port 500 can have fun tracking fragments if they allow
them at all.
The
problem with your option #1 is that you may truly require only 1 end-entity cert
to authenticate main mode - but you SHOULD send multiple CRPs so there is a
higher likelihood that the peer can find one valid end-entity cert that chains
to one of the roots. A gateway which is servicing Internet clients from
multiple PKI domains will have to send one CRP for each PKI domain to each
client, unless you somehow know that only certain PKI domain clients are coming
from some range of IP addresses, or use the MM ID payload to determine which PKI
domain the client might be a member of. Alternately, the clients could
just ignore all the gateway CRPs and send the only end-entity cert they have
which the gateway will validate. But which cert will the gateway send the
client? Obviously only one which the client can validate.
So the client needs to tell the gateway which PKI domain he can validate,
which means sending at least one CRP to the gateway - since the gateway may have
end-entity certs issued from each PKI domain.
Wm
|