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

Re: Certificate Requesting

Ted,

> I had a telephone conversation with Dan Harkins Monday night while he
> was at the interoperabilty conference, and it appears that most
> implementations do assume that IKE takes exactly three round trips, and
> the strategy for handling failures such as not having right certificates
> is to abort the IKE exchange and retry using knowledge gained from the
> previous exchange to do the right thing (such as, sending the CERTREQ
> this time around.)
> 
> Accordingly, Dan was going to modify the IKE spec to remove this point
> of ambiguity by stating that within the IKE DOI, implementations are not
> allowed to send a CERTREQ if doing so would extend the number of
> messages beyond the six specified by the IKE.  If either side doesn't
> have a certificate, they can send a notify message and abort the
> exchange.  
>
> If we assume this strategy, the only thing we are missing is to have the
> ISAKMP spec define a notify message which is "MISSING CERTIFICATE",
> with the data field having the same information as is contained in the
> CERTREQ message.  Notify messages are optional to implement, so
> implementations wouldn't have to do this; however, smart implementations
> would be able note this information and then send the appropriate
> certificate when they retry the IKE negotiation.  Doug, is this
> something you can add to the ISAKMP draft?

Section 4.1 of ISAKMP states that Information Exchanges MUST be
implemented. Notify Payloads are sent via an Informational Exchange, so
implementations must handle the Notify messages, including those that
say MISSING CERTIFICATE or REQUESTED-CERT-UNAVAILABLE (Michael
Richardson's wording).

I'm willing to add this as an additional Notify Message Type as long as
we believe we have *rough* consensus.

> I believe this approach is one for which we can achieve rough
> consensus.  Remember, at this stage of the game the important thing is
> that we choose *one* way of doing things, so that we interoperate, and
> then document it so we can get the specs nailed down and done.

This is in agreement with the following e-mails:
	Angelos Keromytis - 2 Mar 98
	Tero Kivinen - 3 Mar 98
	Michael Richardson - 6 Mar 98

This is not in complete agreement with the following e-mail:
	John Burke - 27 Feb 98

Everyone OK with this approach?

Doug
Follow-Ups: