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

To: Christof Meerwald <cmeerw,AT,web,DOT,de>
Subject: Re: CIPE-Win32: communication breakdown
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Thu, 12 Jun 2003 15:09:08 -0300
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <20030612175030.GA1276@hacking.cmeerw.net>
References: <Pine.LNX.4.44L0.0306121113100.1038-100000@ida.rowland.org> <200306121311.19619.dwilson@ibl.bm> <20030612175030.GA1276@hacking.cmeerw.net>

Ok, I understand your assertion now. In the case of a failed key exchange, 
you're saying that both the old and new dynamic keys should be abandoned by 
the sender and that the (Linux) CIPE receiver has already discarded the
previous dynamic key before it sends the unseen NK_ACK. I wasn't aware about 
that. I'd prefer if the final indication of a successful key exchange was the 
first successful decryption with the new key, thereby allowing subsequent 
discarding of the older key.

Yeah, we need Olaf to comment on this.

Thanks,

DKW

On Thursday 12 June 2003 02:50 pm, Christof Meerwald wrote:
> On Thu, 12 Jun 2003 13:11:19 -0300, Damion Wilson wrote:
> > On Thursday 12 June 2003 12:13 pm, you wrote:
> >> 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).
> >
> > And that's what I do in CIPE-Win32 (I read the same section several
> > times).
>
> Please show me where CIPE-Win32 invalidates the sending key when it sends a
> NK_IND.
>
> I'll try to make it a bit more clear what happens:
>
> CIPE-Win32                      CIPE
>
> encrypt(data, dynamic key 1) -> decrypt(data, dynamic key 1)
>
> NK_IND(new dynamic key 2)    -> install new dynamic decryption key 2
>                                 send NK_ACK (this NK_ACK is lost)
>
> encrypt(data, dynamic key 1) -> decrypt(data, dynamic key 2)
>
>
> and this is what should happen:
>
> CIPE-Win32                      CIPE
>
> encrypt(data, dynamic key 1) -> decrypt(data, dynamic key 1)
>
> NK_IND(new dynamic key 2)    -> install new dynamic decryption key 2
>                                 send NK_ACK (this NK_ACK is lost)
>
> encrypt(data, static key)    -> decrypt(data, static key)
>
> no NK_ACK received for some time, retry keyexchange
> NK_IND(new dynamic key 3)    -> install new dynamic decryption key 3
>                              <- send NK_ACK
> install new dynamic key 3
>
> encrypt(data, dynamic key 3) -> decrypt(data, dynamic key 3)
>
>
> bye, Christof


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