[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Certificate Requesting
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?
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.
Just as a reminder, the internet drafts deadline is March 13 at 1700
EST. Due to the last-minute rush nature of things, we should aim to get
things done by, say, the Wednesday the 11th, so that we have some room
for slop.
- Ted
References: