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

Certificate Requesting



The issue of certificate requesting came up at thursday's IPSec/CA
meeting.  The issue is that the certificate payload is optional when the
authentication method is RSA_SIG, but that the system doesn't know
whether or not the other peer has their certificate.  If the other peer
already has it, then there is no point of sending a 1400 byte
certificate payload in the ISAKMP message. So, this is where the
certificate request payload comes into play.  Unforetunately, there
really hasn't been too much clear text of the usage of this payload.
The specifications state that this payload MAY appear in any exchange,
but it was determined at the IPSec/CA meeting that clearer wording would
be required.

I should also mention that this does not break any of the IPSec
specifications, it only would make this situation clearer to an
implementer.

Only two situations come to mind where the CertReq payload would come in
handy; 

(1) after the authentication exchange has been sent without a
certificate and the other peer did not have or could not get the peer's
certificate or 

(2) during the second exchange where we send over DH public keys and
nonces.  A CertReq here would denote that the peer has no way of
retreiving a certificate so that the other peer must include their
certificate in the next exchange.  

Since the CERT_REQ payload can be located in any exchange, it might be
located on the last message;

        Initiator                          Responder
       ----------                         -----------
        HDR, SA                     -->
                                    <--    HDR, SA
        HDR, KE, Ni                 -->
                                    <--    HDR, KE, Nr
        HDR*, IDii, [ CERT, ] SIG_I -->
                                    <--    HDR*, IDir, [ CERT, ] SIG_R
[, CERTREQ 
        [ HDR*, CERT [, CERTREQ]          --> 
				    [<--    HDR*, CERT ] ] ]
  
This would cause one or two extra messages to occur as in the above
example.

So, can we add wording to the IKE document to clearify this situation so
that we can incorporate this feature for the March 2nd bakeoff?