[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CERT_REQ_PAYLOAD usage
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
In
my opinion, CRP provides a way to establish a trusted CA domain so that both
the initiator and responder can understand they have the ability to validate
the certificate send over through the certificate payload. As the initiator,
if it has multiple certificates issued by different CA's, it SHOULD send
multiple CRPs which contain the different CA DN. As a responder, when it
receives the CRPs, it SHOULD check if it holds any certificate issued by those
CA's, then it has the option to send the certificates which may be validated
by initiator. Otherwise, a certificate received in the certificate payload may
not be validated because the other party doesn't have the right CA
certificate.
Regards!
Kaijun
Well, I thought I would start a thread on one
issue that came up at the VPN Workshop, and that is the usage of the
CERT_REQ_PAYLOAD or CRP.
RFC 2408 states
The Certificate Request Payload
provides a means to request
certificates via ISAKMP and can
appear in any message. Certificate
Request payloads
SHOULD be included in an exchange whenever an
appropriate
directory service (e.g. Secure DNS [DNSSEC]) is not
available to distribute certificates.
and
If multiple certificates are
required,
then multiple Certificate Request payloads SHOULD
be transmitted.
The behaviour I saw was one of the
following.
1) Initiator sends CRP per cert required, and
responder replies with the appropriate certificates.
2) Initiator sends 1 CRP, and the responder
sends all certs.
3) Initiator does not send CRP, but wants all
certs because RSA was negotiated.
I am sure there are others. I would like to
recommend that option 1 is the best option, and the simplest. This has
caused many interop issues, and the vague wording does not help. I would
like to tighten up the rules if possible.
Comments?
Regards
Scott
Fanning