<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: Alan Stern <stern,AT,rowland,DOT,harvard,DOT,edu>
Subject: Re: CIPE-Win32: communication breakdown
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Thu, 12 Jun 2003 13:11:19 -0300
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <Pine.LNX.4.44L0.0306121113100.1038-100000@ida.rowland.org>
References: <Pine.LNX.4.44L0.0306121113100.1038-100000@ida.rowland.org>

And that's what I do in CIPE-Win32 (I read the same section several times).

If you read Christof's message of June 6, he asserts that there is a key 
negotiation problem over less reliable links due to CIPE invalidating the
key before the NK_ACK and CIPE-Win32 continuing to use the key until
the NK_ACK.

I think that's right. When in doubt, both sides should use the static key, 
which they do.

DKW

On Thursday 12 June 2003 12:13 pm, you wrote:
> On Mon, 9 Jun 2003, Damion Wilson wrote:
> > Christof is saying that the peer starts using the new key without the
> > ACK. I'm the one saying that CIPE-Win32 doesn't use its newly generated
> > key until the ACK is sent back. Who are you agreeing with ?
> >
> > DKW
>
> Sorry, I think we got a little confused over which CIPE is doing what.  If
> it helps, here is a direct quote from cipe.texinfo:
>
>   The key negotiation procedure normally runs as follows: The sender
>   sends a NK_IND with the new key, then invalidates its own sending key.
>   Upon receipt of NK_IND, the receiver starts using this key as its
>   receiving key and sends a NK_ACK. When the sender receives NK_ACK, it
>   starts using the new key as its sending key. If either of NK_IND or
>   NK_ACK is lost in transmission, no new key will be used. The sender
>   should send a new NK_IND (with new key) if no matching NK_ACK is
>   received within a reasonable amount of time (current specification: 10
>   seconds).
>
> The unmentioned implication is that during the period when the old and new
> sending keys are both invalid, the sender falls back on the static key.
>
> That should clear things up.
>
> Alan Stern
>
> > On Friday 06 June 2003 04:31 pm, Alan Stern wrote:
> > > On Fri, 6 Jun 2003, Damion K. Wilson wrote:
> > > > I don't think that this approach is wrong, and it's intentionally
> > > > written that way. If A says to B: "I'm changing my  key, here it is"
> > > > and B never says: "I got it, go ahead" then there has been no
> > > > successful key exchange so both A and B must try again.
> > > >
> > > > I didn't know that CIPE invalidates the key before receipt of the
> > > > NK_IND has been acknowledged by the peer. It the NK_ACK wasn't
> > > > necessary, why have it at all ?
> > > >
> > > > Olaf, if you're listening, do you have any guidance ?
> > >
> > > My memory may be a little rusty, but I think Christof was right.  The
> > > reason for the NK_ACK message is that CIPE won't start to use the new
> > > key until the NK_ACK is received.  Until then it will fall back on the
> > > static key.
> > >
> > > At least, that's what the documentation says.  Maybe the implementation
> > > is different.
> > >
> > > Alan Stern


<< | Thread Index | >> ]    [ << | Date Index | >> ]