[asterisk-dev] Re: AstriDevCon Recap - IAX2 RENEW for encryption

[Tony Mountifield]

In article <465F5831.2040903 at digium.com>,
Russell Bryant <russell at digium.com> wrote:
> Kevin P. Fleming wrote:
> > A couple of other comments: is there any value in making an assumption 
> > that key usage is symmetrical? For example, if peer A sends RENEW with 
> > ENCKEY, and peer B sends ACCEPT, could that mean that _only_ packets 
> > from A->B are encrypted using the new key, and that peer B should also 
> > send RENEW/ENCKEY to change keys in the B->A direction (possibly to the 
> > same key, possibly to a different key)?
> 
> I noted in another response to this thread that I think this RENEW with 
> ENCKEY method should only change the encryption key in one direction.
> 
> Also, another thing I brought up is that I don't think an ACCEPT should 
> be required.
> 
> If you switch to decrypting using the new key as soon as you receive the 
> RENEW, then every frame you receive after that (assuming they are in 
> order) is encrypted using the new key.  If the peer that sends the RENEW 
> does not switch to encrypting using the new key until after it receives 
> the ACCEPT to your RENEW, then there is no way to synchronize the key 
> switch with the other end.  You send the ACCEPT, and then the other side 
>   will switch whenever it receives it, but there is no way to know when 
> that is.

You could consider a scheme which is used in DVB television conditional
access encryption, where the encryption key (known as the Control Word) is
typically changed every 10 seconds. Keys are labelled "odd" and "even"
alternately. Data packets include a header that indicates whether it was
encrypted with the odd or even key. The receiver always keeps a copy of
both current keys.  While the sender is using the odd key, it is free to
update the even key, and vice versa.

In DVB, which is one-way, the key transmission is repeated periodically
to overcome lost packets, and enough time is left after changing a key
before starting to use it.

In the IAX scenario, having updated the even key, it would continue using
the odd key for encryption until it received an ack of the change to the
even key from the peer. It would then be free to start using the even key
at some point, and at any time later to update the odd key.

This would completely avoid race conditions between updating the key and
using the updated key.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org