[asterisk-dev] AstriDevCon Recap - IAX2 RENEW for encryption
Kevin P. Fleming
kpfleming at digium.com
Thu May 31 14:58:09 MST 2007
Steve Kann wrote:
> 3) I'm not sure when we'd actually want to switch encryption keys, in
> each direction. We would need to consider that there is some latency
> between when we send packets, and when they're received, and the latency
> is often going to be larger than the inter-packet interval.
> RENEW+ACCEPT probably handles this properly, but not in a backwards
> compatible way:
>
> a) When a sender sends a RENEW packet with a new ENCKEY IE, it shall
> be encrypted with the old key. Subsequent packets shall be encrypted
> with the new encryption key.
I think I agree with Mihai's point later in this thread; the sender of
the RENEW should not switch to the new key until the handshake has been
completed via reception of a corresponding ACCEPT.
> b) When the recipeient of a RENEW packet with an ENCKEY IE receives
> that key, it shall expect subsequent packets from that sender to be
> encrypted with the new key. It also shall send an ACCEPT packet,
> encoded with the old ENCKEY, and then send subsequent packets encrypted
> with the new encryption key.
> c) When the sender of a RENEW packet receives an ACCEPT packet from
> it's peer, it shall expect all subsequent packets to be encrypted with
> the new key.
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)?
There is a thought in my mind that the implicit symmetrical key change
is going to cause problems if packets are lost or delivered out of
order, but I could be mistaken... I haven't worked with as much IAX2
traffic as the others in this thread have :-)
--
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)
More information about the asterisk-dev
mailing list