[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
On Wed, 16 Sep 1998 14:58:16 EDT you wrote
> > 3. Clarification of use of the commit bit in IKE. This will constrain
> > the freeform (and confusing) verbage in the base ISAKMP document.
> > For IKE the commit bit only makes sense in Quick Mode. Most people
> > I spoke to said that they return a "INVALID_FLAGS" notify message
> > if the peer tries to set it in any other mode. They also only use it
> > to extend Quick Mode by a single message-- from the responder back
> > to the initiator. This was its intended use anyway. Also, most
> > people send this message as a final Quick Mode exchange message
> > and not an Informational. The only person I spoke to who did
> > otherwise said Quick Mode made more sense and was going to change.
>
> So that final Quick Mode message would presumably include the "CONNECTED"
> Notify payload, right? Would there also be a Hash payload to authenticate
> it? If so, what goes in that hash? If people are already implementing
> this, it'd be nice to know how it's done...
Yes, it would contain the CONNECTED message. And all Quick Mode messages
are authenticated with an hmac which is keyed with SKEYID_a (and they're
all encrypted with SKEYID_e).
> Also, is the initiator required to send the commit bit in the third Quick
> Mode message if it requires the fourth "CONNECTED" message, or does the
> responder always need to keep an eye out for it earlier on in the exchange
> (perhaps even as early as Phase 1?)?
What do other people think? I imagine either party could set it and it
could be set in any message.
Dan.
Follow-Ups:
References: