[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: