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

[irroot]

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

(Updated Aug. 27, 2011, 2:28 a.m.)


Review request for Asterisk Developers and Olle E Johansson.


Changes
-------

New patch without the "encryption=try" optional / attempt SRTP bits it confuses the core issue of fixing the bug not setting the taglen correctly.

updated description to prevent confusion as seen by oej the option to set the taglen is "encryption_taglen=" the default is 80.

added oej onto the list after he so kindly reviewed it.


Summary (updated)
-------


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 (updated)
-----

  /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 
  /branches/10/CHANGES 333337 
  /branches/10/channels/chan_sip.c 333337 

Diff: https://reviewboard.asterisk.org/r/1173/diff


Testing (updated)
-------

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/20110827/e43cca31/attachment.htm>