[asterisk-dev] [Code Review]: Allow Setting Auth Tag Bit length Based on invite or config option [BUG]

irroot reviewboard at asterisk.org
Mon Aug 29 08:09:29 CDT 2011 


> On Aug. 28, 2011, 7:37 a.m., nixon wrote:
> > Perfect work! Great thanks!
> 
> irroot wrote:
>     Thank you are you currently using this code / tested it ?? feed back is vaulued
> 
> nixon wrote:
>     I have softphone Groundwire by Acrobits Software on iPhone4.
>     
>     [5004]
>     ...
>     encryption=yes
>     encryption_taglen=32 ;if comment this setting all work anywere, but without patch is no
>     transport=tls
>     directmedia=update,nonat
>     nat=yes
>     disallow=all
>     allow=g722
>     
>     Media is ok now, but I still have next result. How can to fix that?...
>     
>     [Aug 29 12:53:43] WARNING[18774]: res_srtp.c:385 ast_srtp_unprotect: SRTP unprotect: unsupported parameter
>     [Aug 29 12:53:43] WARNING[18774]: res_srtp.c:385 ast_srtp_unprotect: SRTP unprotect: authentication failure
>         -- AGI Script Executing Application: (DIAL) Options: (SIP/prov1/0012345678910,60,HRL(5689000:60000:30000)T)
>       == Using SIP RTP TOS bits 184
>       == Using SIP RTP CoS mark 5
>         -- Called SIP/prov1/0012345678910
>         -- SIP/90094-000000f6 is making progress passing it to SIP/5004-000000f5
>     [Aug 29 12:53:50] WARNING[18774]: res_srtp.c:385 ast_srtp_unprotect: SRTP unprotect: authentication failure
>         -- SIP/prov1-000000f6 is ringing
>     [Aug 29 12:53:52] WARNING[18774]: res_srtp.c:385 ast_srtp_unprotect: SRTP unprotect: authentication failure
>     [Aug 29 12:53:59] WARNING[18774]: res_srtp.c:385 ast_srtp_unprotect: SRTP unprotect: authentication failure
>         -- SIP/prov1-000000f6 answered SIP/5004-000000f5
>     [Aug 29 12:54:05] WARNING[18774]: res_srtp.c:385 ast_srtp_unprotect: SRTP unprotect: authentication failure
>     
>     Have testing CSipSimple for Android with SRTP/TLS - no WARNINGs.

Thx for the feedback the warnings above i have seen on my own systems as far as i can tell these are frames that are transmited without the SRTP configured first and not related to the fix of this patch and are not a problem


- irroot


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


On Aug. 27, 2011, 2:42 a.m., irroot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1173/
> -----------------------------------------------------------
> 
> (Updated Aug. 27, 2011, 2:42 a.m.)
> 
> 
> Review request for Asterisk Developers and Olle E Johansson.
> 
> 
> Summary
> -------
> 
> 
> Correctly handle the SRTP tag length either 32/80 this is not the key length / cipher strength.
> currently only 80 is supported introducing problems.
> 
> the taglen in the incoming invite always is used outgoing invites will have the configured taglen [default 80] this fixes a serious interop issue and bug where the taglen was always set to 80 regardles of the incoming invite.
> also there was no way to set the taglen for a new invite.
> 
> 4.1 Crypto-suites 
>     
>    A crypto-suite value appears as the first parameter in a=crypto. The 
>    CRYPTO-SUITE value MAY be different for SRTP and SRTCP as described 
>    in Section 4.2. If a receiver does not support the particular 
>    crypto-suite, then the receiver MUST NOT participate in the media 
>    stream and SHOULD log an "unrecognized crypto-suite" condition 
>    unless the receiver is participating in an Offer/Answer exchange 
>    (Section 5).  RTP/SAVP has four crypto-suites as described below. 
>     
> 4.1.1 AES_CM_128_HMAC_SHA1_80 
>     
>    This is the SRTP default AES Counter Mode cipher and HMAC-SHA1 
>    message authentication having a 80-bit authentication tag.  The 
>    encryption and authentication key lengths are 128 bits.  The master 
>    salt value is 112 bits and the session salt value is 112 bits.  The 
>    PRF is the default SRTP pseudo-random function that uses AES Counter 
>    Mode with a 128-bit key length.   
>  
> 4.1.2 AES_CM_128_HMAC_SHA1_32 
>     
>    The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message 
>    authentication having an 32-bit authentication tag.  The encryption 
>    and authentication key lengths are 128 bits.  The master salt value 
>    is 112 bits and the session salt value is 112 bits.  These values 
>    apply to SRTP and to SRTCP.  The PRF is the default SRTP pseudo-
>    random function that uses AES Counter Mode with a 128-bit key 
>    length.  
>  
> 4.1.3 F8_128_HMAC_SHA1_80 
>     
>    The SRTP f8 cipher is used with HMAC-SHA1 message authentication 
>    having a 80-bit authentication tag.  The encryption and 
>    authentication key lengths are 128 bits.  The master salt value is 
>    112 bits and the session salt value is 112 bits.  The PRF is the 
>    default SRTP pseudo-random function that uses AES Counter Mode with 
>    a 128-bit key length.  
>     
> 4.1.4 F8_128_HMAC_SHA1_32 
>     
>    The SRTP f8 cipher is used with HMAC-SHA1 message authentication 
>    having a 32-bit authentication tag.  The encryption and  
>    authentication key lengths are 128 bits.  The master salt value is 
>    112 bits and the session salt value is 112 bits.  The PRF is the 
>    default SRTP pseudo-random function that uses AES Counter Mode with 
>    a 128-bit key length.  
> 
> 
> This addresses bug 19335.
>     https://issues.asterisk.org/jira/browse/19335
> 
> 
> Diffs
> -----
> 
>   /branches/10/CHANGES 333337 
>   /branches/10/channels/chan_sip.c 333337 
>   /branches/10/channels/sip/include/sdp_crypto.h 333337 
>   /branches/10/channels/sip/include/sip.h 333337 
>   /branches/10/channels/sip/include/srtp.h 333337 
>   /branches/10/channels/sip/sdp_crypto.c 333337 
>   /branches/10/configs/sip.conf.sample 333337 
> 
> Diff: https://reviewboard.asterisk.org/r/1173/diff
> 
> 
> Testing
> -------
> 
> This has been rolled out to > 50 sites using 32 and 80 bit taglen.
> 
> the optional element has been removed from this patch to make the core bugfix see it to v10
> 
> 
> Thanks,
> 
> irroot
> 
>

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

More information about the asterisk-dev mailing list