[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Certificate Requesting
The extra round trip was because we don't know that we do not have that
certificate because we do not have the ID yet.
This scenario was put forth by Rob Adams at the IPSec CA meeting and I
do see his point. IP Address are usually not good enough to find a
certificate, thus we must wait for the ID.
>-----Original Message-----
>From: Daniel Harkins [SMTP:dharkins@cisco.com]
>Sent: Monday, February 23, 1998 4:18 PM
>To: Roy Pereira
>Cc: 'Greg Carter'; 'IPSEC Mailing List (E-mail)'
>Subject: Re: Certificate Requesting
>
> Roy,
>
>> 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.
>[snip]
>
> Perhaps I'm missing something here but you're asking for the cert's
>too late. You need them to verify the signature but you're not asking
>for them until you've already, presumably, authenticated your security
>association by checking the peer's signature.
>
>>> 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 ] ] ]
>>>
>
>If the Initiator didn't send his cert in his 3rd message then the
>responder wouldn't be able to verify his signature and would abort
>the communication. Why not send a CERTREQ in the 2nd messages. That
>way you're still keeping a modicum of identity protection (sending it
>in the 1st messages requires the other party to respond with his cert
>in the clear).
>
>At the point you're sending the KE and nonce payloads you know what your
>authentication method is. If it's signature based and you don't have a
>cert for the peer (granted it's tough to know if you do since all you have
>to go on at that point is IP address and not everyone will be encoding an
>IP address in their certs) send the CERTREQ then.
>
>Why the need for the extra round trip? And the suspension of authentication
>and retention of state? Am I missing something here?
>
> Dan.
>