Re: [AVTCORE] AES-GCM SRTP (RFC 7714) KDF implementation

Ekr, Martin, 

Any thoughts on this ?

Thanks

> On Aug 4, 2016, at 9:45 PM, Paul E. Jones <paulej@packetizer.com> wrote:
> 
> AVT,
> 
> There are now at least two implementation of RFC 7714 and at least two interpretations of how to treat the master salt value when used with in KDF.  So that we can ensure consistent implementation, it was suggested that I bring this issue to the WG.
> 
> The issue has to do with the salt length and the KDF.  As you know, RFC 3711 uses AES-CM for the KDF and assumes an initial SRTP master salt that is 14 octets in length (see section 5.3/RFC3711).  AES-GCM, though, utilizes a 12 octet salt value.
> 
> We have this when AES-CM is used (example taken from RFC 3711) with a 14 octet salt:
>  
>       index DIV kdr:                 000000000000
>       label:                       02
>       master salt:   0EC675AD498AFEEBB6960B3AABE6
>       -----------------------------------------------
>       xor:           0EC675AD498AFEE9B6960B3AABE6     (x, PRF input)
> 
>  
> This value is then multiplied by 2^16 per 4.3.3/RFC3711 (i.e., pad zeros on the right) to produce a 16-octet salt value that is then used in the AES-CM KDF logic.
> 
> When the 12 octet salt used in AES-GCM is provided, libsrtp (https://github.com/cisco/libsrtp) will assume that zeros are padded on the right to produce a 14-octet salt value (to get the default master salt length needed per section 5.3).  Thus, assuming a salt value of 0EC675AD498AFEEBB6960B3A, these steps are performed:
>  
>       index DIV kdr:                 000000000000
>       label:                       02
>       master salt:   0EC675AD498AFEEBB6960B3A
> 0000
>      (two padding octets on the right)
>       -----------------------------------------------
>       xor:           0EC675AD498AFEE9B6960B3A0000     (x, PRF input)
> 
>  
> Again, this value is then multiplied by 2^16 per 4.3.3/RFC3711 (i.e., pad zeros on the right) to produce a 16-octet salt value that is then used in the AES-CM KDF logic.
> 
> However, there is a statement in 4.3.1/RFC3711 that says "Let x = key_id XOR master_salt, where key_id and master_salt are aligned so that their least significant bits agree (right-alignment)."  That might suggest that the XOR should have been performed without padding as shown above and as implemented in libsrtp.
>  
> If padding on the right was the wrong thing to do, that would mean that the XOR step using the initial 12 octet AES-GCM salt should have been this:
>  
>       index DIV kdr:             000000000000
>       label:                   02
>       master salt:   0EC675AD498AFEEBB6960B3A
>       -------------------------------------------
>       xor:           0EC675AD4988FEEBB6960B3A     (x, PRF input)
> 
>  
> Then the x*2^16 operation that then follows as per 4.3.3/RFC3711 would result in:
> 0EC675AD4988FEEBB6960B3A0000
>  
> However, this is only a 14 octet value and we need 16 octets for the AES-CM KDF (which was the reason the step in 4.3.3 exists for the default 14 octet salt).  Thus, we are short two octets.
> 
> We either need to pad the initial 12 octet AES-GCM input salt at the start in some way to form the expected 14 octet salt value expected per section 5.3 (the approach taken by libsrtp), or we need additional padding after the above x*2^16 step (e.g., introduce a second x*2^16 step).
> 
> Given that at least two implementers interpreted the specs differently, I think it would be of benefit to discuss this in the WG and document the proper behavior.
> 
> Paul
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt