[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability





Thank you so much for your clear response.  I am glad you interpret receiving
multiple cert request payloads as an opportunity to scan for one until you find
in your own cert cache one which has a root that matches the info in one of the
cert payloads.  I am concerned that some of the other vendors might not
interpret multiple cert requests received in that way due to the verbage in
ISAKMP, Section 3.10:  "If multiple certificates are required, then multiple
Certificate Request payloads SHOULD be transmitted".  This gives me the wrong
impression on the use of multiple cert requests.  I would want to send multiple
cert request payloads NOT because I necessarily want multiple certificates.  I
would send them because I support multiple roots and hope that one of the roots
is supported by the peer and so I give you the list of roots I support so that
you can choose an entity cert (or certificate chain) to send me rooted on one of
these.

 Probably ISAKMP should rather say something like this:

"If multiple root certificate authority certificates are supported by a device,
then it SHOULD send a separate certificate payload for each of these certificate
authority roots.  On receiving multiple certificate request payloads, the
responder MUST send at least one end entity certificate (or certificate chain)
that is rooted on  one of these certificate authorities if it is available."

At the VPN bakeoff group meeting, I even questioned the utility of certificate
request payloads.  This mostly seems like an optimization.  If vendors, having
negotiated the use of certificates for IKE authentication, were to always send a
certificate regardless of receiving a certificate request payload, then the
worst that can happen is that there is additional certificate content in the IKE
messages exchanged (when it might not be necessary) and that a certificate
selected by one side does not have a corresponding root recognized by the peer
and the negotiation fails.  The certificate request payloads streamlines the
protocol by preventing long certificate content being sent when:

1.  As you mentioned, one side has already cached the other side's certificate
information

2.  When repositories are available (like LDAP directories) that can store
certificates, which can be fetched directly without asking for them from the
peer.  The question arises in this case as to how a device knows how to fetch
from the repository the peer's certificate (e.g. what distinguished name to use
in the directory READ request).  Probably some policy configuration would be
needed to correlate peer identity with the repository fetching info (like
distinguished name).

Using an empty certificate request (i.e. with no "certificate authority" field)
as agreed upon by the VPN bakeoff group runs the same risk as not sending a
certificate request payload and having the vendor just interpret this as to
return some certificate.  If the certificate returned matches a root maintained
by the device, then fine (with everything else being validated) the certificate
is validated.  If the cert returned happens not to have a root that is trusted
by the device, then the negotiation will fail.  So what difference is there
between sending empty certificate requests and not sending any and requiring
that the peer always respond with some certificate outside of the optimization
of preventing unnecessary long IKE message (with unneeded cert content)?

The only other place where certificate requests may have utility is if the peer
receiving the request actually has multiple end entity certificates, each one
issued by a different root.  In that case a device should issue the cert request
payload so that the peer can choose the right one to improve chances of
interoperability.  However, what I questioned is whether a device having
multiple end entity certs, each issued by a different root, is realistic.  Each
device belongs in general to one security domain, with some administrator
managing the security attributes of that device.  Generally the certificate
issued to the device authenticates the keys generated for use minimally within
that domain.  If there was another certificate issued by another CA to that
device, then we would have 2 security domains authenticating the single device.
(This is different than the valid situation in which one CA issues multiple
certs to the device, say, for different keys or different applications with
different extensions for the same keys.)  So I was questioning whether having a
single device authenticated by 2 domains makes sense.  If it does, I would
appreciate someone giving me a realistic scenario and where this applies.  If
such a scenario exists, this will ease my concerns considerably about the
utility of certificate request payloads.  I thank anyone who can help me in this
matter.






Jan Vilhuber <vilhuber@cisco.com> on 01/25/2000 09:39:14 PM

Sent by:  Jan Vilhuber <vilhuber@cisco.com>


To:   Allen Rochkind/HQ/3Com
cc:   ipsec@lists.tislabs.com
Subject:  Re: Request for Clarification of Usage of Certificate Request Payload
      to Maximimze Interoperability




On Tue, 25 Jan 2000 Allen_Rochkind@3com.com wrote:
>
>
> At the recent VPN bakeoff, several vendors REQUIRED the peer to send a
> Certificate Request payload during the IKE main mode exchange (using
> signature authentication) in order for their system to send the peer its
> certificate (i.e.  no Certificate Request payload received results in no
> certificate being sent back to the peer in the final main mode exchange).

Makes sense to me. Certs can be large and I might have cached it the last
time I asked you. If I don't ask you to send me one, don't send it.

> Looking at the ISAKMP spec (Section 3.10) it appears that only one
> Certificate Authority DER encoded distinguished name (for X.509 certificate
> type) can appear in the certificate request payload.  Normally if the 2
> systems in the exchange were in the same security domain governed by a
> single root CA, one peer would put the distinguished name of that CA's
> certificate subject in the payload and the other system would then choose
> to send back a chain of certs rooted on that CA.

Ahm.. not "choose to send back". The rfc says: "The responder to the
Certificate Request payload MUST send its certificate, if certificates are
supported...".

> However, in the case of
> extranet interaction in which it is possible that a given system might
> interact with several different security domains (each with its own CA) it
> is unclear what certificate authority distinguished name should be put in
> the certificate request payload.  E.g. it may be possible that the local
> system trusts several different roots to handle the diversity of different
> extranet security domains it wants to deal with.  In any given IKE exchange
> it would not know in advance which certificate authority it should ask in
> the certificate payload to be the root of the returned certificate
> requested unless there is some elaborate policy mapping between identities
> and trusted root CAs at the other end.
>
> To maximize interoperability, should one send multiple certificate
> requests, each corresponding to a CA that is trusted, and hope that the
> responder will find in one of the certificate request payloads the
> distinguished name for the root certificate that its end entity certificate
> is based on?

Yes. The rfc talks about 'Certificate Request payloads', i.e. plural, so I
would assume it's perfectly legal to send multiples. We tested with a few
vendors in San Diego that did this.

> Alternatively ISAKMP says, "If there is no specific
> certificate authority requested, this field [the Certificate Authority
> field] SHOULD not be included."  Then would it be safer to ensure
> interoperability to simply send one certificate request always with no
> "Certificate Authority" field entered in the certificate request payload?

Depends on what you believe is right (see below).

> If that is so, what good does sending a certificate request payload do?

As was established by consensus at the bakeoff, an empty CERT_REQ payload
means "send me any cert at all". See message:

     issues raised at VPN interoperability workshop, Dan Harkins
     <dharkins@network-alchemy.com>, Tue, 18 Jan 2000 16:05:44 -0800 (PST)

       * What does an empty cert request payload mean?

       "give me a cert; any cert".


Personally, I find that a bit hard to believe, since I might send you a
certificate from CA FOOBAR, which you've never heard of, so I'm not sure what
good an empty CERT_REQ will do you, but that was the consensus.

I guess if you are willing to send empty CERT_REQs you are implying that you
can handle EVERY possible known CA on the planet (and beyond!).

> What is the practice of the various vendors that send certificate request
> payloads or expect other vendors to send them in order to send back their
> own certificate chains in the IKE exchange?
>
- If we don't get a CERT_REQ, we won't send a cert.
- If we receive multiple cert-requests, we blue-screen.
  Just kidding: We go through them one by one and the first one we have a
  cert for, we send it (we might even send multiple, i.e. signature and key
  exchange, if you asked for both)
- If we get an empty CERT_REQ, we won't honor it and fail the exchange
  (probably not the right thing to do either, in light of the consensus
  mentioned above). I'll probably change that to send you the first one on my
  list (for whatever that's worth). Maybe I'll even keep a counter of how
  many times a certain cert was requested and send you the one that was LEAST
  requested, just so it doesn't feel left out ;)

jan
 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847







Follow-Ups: