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

[Steve Kann]

Russell Bryant 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.
>

This all makes sense -- the only reason I brought ACCEPT into the 
picture, then, was to make it work the same as the codec re-negotiation 
stuff that we discussed;  where you'd send a RENEW with new format 
requests, and then your peer would reply with ACCEPT and the formats 
they chose, etc.   If RENEW used only for encryption key changes behaves 
differently then RENEW with format negotiation payloads, then it could 
make things a bit confusing -- for example, what happens if someone 
sends RENEW with ENCKEY _and_ format negotiation payloads?  Do you 
handle the ENCKEY immediately, and then use ACCEPT for the format stuff? 

Perhaps something that makes it all orthogonal, and doesn't have a race, 
is if peer A sends "RENEW+ENCKEY(A2)", then peer B can reply with ACCEPT 
"RENEW+ENCKEY(B2)", and then as each peer sends their respective ENCKEY 
payloads, they'd send subsequent packets using these new keys (A2 or 
B2).  If peer B wants to use the same key as A, it could reply with 
ENCKEY(A2) as well, and the encryption would use the same key in both 
directions, or peer B could reply with the old key, if it wanted to keep 
using the old key.  We can make the sending of ACCEPT, in this case, a 
SHOULD instead of a MUST, otherwise we would probably want to also 
specify what peer A would do if it did not get the ACCEPT.

-SteveK