[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CERT_REQ_PAYLOAD usage
Unless
I'm missing something, it seems pretty hacky to send multiple end entity cert
chains. Say my peer sends me 3 CRPs for different roots, root A,B,C.
I have 3 cert chains that chain to these roots. Chain1:
A0,A1,A Chain2: B0,B1,B2,B Chain3: C0,C1,C where A0, B0,
and C0 are the end entity certs.
Say I
send all of these certs in random order (A0,B1,A1,B0,C0 etc). Now, the
peer has to pick out the chains, and piece them back together. Worse yet,
I also have to send 3 sig payloads since in general A0,B0 and C0 will all have
different private keys. There is no way in IKE to map the chain to the sig
payload, so IKE has to guess what the chains are, guess what the end entity
certs are, and go with trial and error to find the correct sig payloads.
Thus,
sending a single chain and a single sig payload seem to me to be the only
reasonable alternative. Of course, if we mandated that people sent an
individual chain as its own PKCS7 and that all end entity certs MUST have the
basic constraint saying that they are end entity, and defined some way in IKE to
map PKCS blobs to sig payloads (maybe with mandatory payload ordering), then
perhaps we could build an interoperable way to send multiple chains. But
as William points out, we'd still have the problem of fragmented IKE
payloads.
bs
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
Follow-Ups: