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

[Tim Panton]

On 3 Jun 2007, at 23:06, Steve Kann wrote:

> 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

We discussed this after you had left, and I started out from your  
viewpoint, but I was convinced by Mark's argument,
which was (in essence):
	1) We are only doing RENEW for key rotation at the moment
	2) In that case both ends have already agreed to use a specific  
encryption format, so it makes no sense to
allow anything other than an ACK (or a RENEW with the recieve key).
ACCEPT implies some form of negotiation, and in the case of  
encryption there isn't anything to negotiate.
  (except agreeing to drop encryption half way into the call which  
isn't desirable.)
	3) We could use a different frame type for the (video) format.

For me the only question is: is RENEW the wrong name - should we call  
it ROTATE ?

T.

Tim Panton

www.mexuar.net
www.westhawk.co.uk/