[asterisk-dev] [Code Review]: Respond with correct SRTP crypto policy in Asterisk 1.8; only re-create SRTP session when needed

[Matt Jordan]

> On Sept. 8, 2012, 12:34 p.m., Joshua Colp wrote:
> > ./branches/1.8/channels/sip/sdp_crypto.c, line 274
> > <https://reviewboard.asterisk.org/r/2099/diff/1/?file=31147#file31147line274>
> >
> >     There is no limit on the length of suite so an attacker could exceed the size you have chosen.

Yikes.  Fixed.


> On Sept. 8, 2012, 12:34 p.m., Joshua Colp wrote:
> > ./branches/1.8/channels/sip/sdp_crypto.c, line 294
> > <https://reviewboard.asterisk.org/r/2099/diff/1/?file=31147#file31147line294>
> >
> >     Wow'sa.

My thoughts exactly.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2099/#review7029
-----------------------------------------------------------


On Sept. 6, 2012, 4:17 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2099/
> -----------------------------------------------------------
> 
> (Updated Sept. 6, 2012, 4:17 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Handling for multiple SRTP keys and re-negotiation of the SRTP keys was fixed in previous versions of Asterisk 1.8.  In the process, it became apparent that in certain re-INVITE scenarios, with certain models of phones, re-negotiating the keys caused issues when the phones were taken off hold.  Specifically, certain models of phones would send RTP packets to Asterisk that failed the authentication check, even though the policy had been renewed with the newly agreed upon keys.
> 
> In addition, while testing, it was found that phones that offer AST_AES_CM_128_HMAC_SHA1_32 will end up with no audio if the phone is the initiator of the call.  The phone will send an INVITE request specifying that AST_AES_CM_128_HMAC_SHA1_32 be used for the cryptographic policy; Asterisk will set its policy to that value.  Unfortunately, when the call is Answered and a 200 OK is sent back to the UA, the policy sent in the 200's SDP will the be hard coded AST_AES_CM_128_HMAC_SHA1_80.  This is only a problem in Asterisk 1.8, as Asterisk 10 fixed this problem when it introduced the ability to have the cryptographic policy configurable.
> 
> This patch fixes both problems: first, it caches the remote key received from the UA and only re-creates the SRTP session if the UA has sent a new remote key.  Second, it caches the crypto policy sent by the UA (which is what Asterisk will use internally for the SRTP session already), and responds with that crypto policy in the response to the INVITE.
> 
> 
> This addresses bug ASTERISK-20194.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20194
> 
> 
> Diffs
> -----
> 
>   ./branches/1.8/channels/sip/sdp_crypto.c 371988 
> 
> Diff: https://reviewboard.asterisk.org/r/2099/diff
> 
> 
> Testing
> -------
> 
> Tested with Aastra and SNOM 320 model phones.  While the initial bug that the issue reporter had could not be reproduced with these phones (and firmware revisions), with this patch calls could be established between the two phones (using different crypto policies) and re-INVITEs could be sent without causing issues.
> 
> The issue reporter also confirmed that the patch resolved the issue they were experiencing with their phone models.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120908/7258eb25/attachment.htm>