[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

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: References: