[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Certificate Requesting
The additional exchange scenario that you do not agree with only happens
if the initiator does not send a certificate and the responder does not
have it. The responder will then append a CertReq payload to the ISAKMP
message. If the initiator receives the CertReq in the sixth message of
MainMode (RSA_SIG), then he must reply back with his certificate in a
MainMode message. He may also append a CertReq to that message if the
responder did not include a certificate in the sixth message and he does
not have it. This would force the responder to reply back with his
certificate.
This scenario was brought forth by a rather large software corporation
since this is what they do in their IPSec implementation.
>-----Original Message-----
>From: Greg Carter [SMTP:greg.carter@entrust.com]
>Sent: Friday, February 20, 1998 6:55 PM
>To: Roy Pereira; 'IPSEC Mailing List (E-mail)'; 'Dan Harkins (E-mail)'
>Subject: RE: Certificate Requesting
>
>Hi Roy,
>
>I know a few IKE's that will accept the Cert Req in the SA exchange, the
>KE, or the final ID part. I really don't what to see the case you
>propose as even being valid (additional exchange). For one it allows
>for an awful state on the responder. Take this situation
>
>> Initiator Responder
>> ---------- -----------
>> HDR, SA -->
>> <-- HDR, SA
>> HDR, KE, Ni -->
>> <-- HDR, KE, Nr
>> HDR*, IDii,CERT, SIG_I -->
>> <-- HDR*, IDir, SIG_R
>
>If I am the Responder I have all I need, my main mode is done. But now
>I have to keep it open just in case you want to send me a cert request
>payload.
>
>No sir, No sir, I don't like it.
>
>> HDR*, CERTREQ -->
>
>You can't do it under an info because the Responder has gone to the
>Encrypt only state because he has a valid SA.
>
>ISAKMP states that optional payloads must be accepted any time during
>the exchange, to me this doesn't mean it is valid to extend the exchange
>>to send optional payloads.
>
>Send your Cert Req either during SA, KE, or ID exchanges. Don't tack on
>an additional exchange. I know this isn't the greatest because you
>don't have the ID payload until the last exchange. Well then you cache
>certs based on IP, or you cache certs based on SA, or you send over your
>Vendor Specific cert cache info payload, or just don't cache certs and
>live with the 1k of additional data as opposed to the headaches you are
>going to cause yourself with caching...
>Bye.
>----
>Greg Carter, Entrust Technologies
>greg.carter@entrust.com
>
>
>>----------
>>From: Roy Pereira[SMTP:rpereira@TimeStep.com]
>>Sent: Friday, February 20, 1998 4:48 PM
>>To: IPSEC Mailing List (E-mail); Dan Harkins (E-mail)
>>Subject: 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?
>>
Follow-Ups: