paulej
commented
8 years ago As Alexander noted in his reply, changing the current behavior will break existing deployments.
We do need to get clarity on this issue. I hope to see Dave McGrew at the IETF next week. Perhaps I can get his view on this while there.
I can easily see arguments for both ways on this. Section 4.1.1/RFC 3711 describes working with a salt with AES CM which is a 14 octet value. Since AES GCM uses a 12 octet value, two additional octets were needed somewhere. Libsrtp took the option of adding those on the right.
Equally valid given there appears to be no explicit statement on this, the padding could have been on the left.
The specs simply do not state where padding should be added, but padding is definitely need to use that salt with the KDF. At least I cannot find it.
JonathanLennox
traud
pabuhler
RFC 7714 Sec 11. states that AEAD_AES_128_GCM must use the KDF as defined in RFC 3711 Sec 4.3.1.
IV generation for this KDF is defined in RFC 3711 Sec 4.3.3:
IV [is] equal to (x*2^16)where x is the master salt.The problem arises because the master IV for AES-GCM is 12 bytes, as opposed to 14 bytes for the default AES-CM algorithm specified in RFC 3711. Appendix B.3 has a test vector for IV generation. A 14 byte master salt of
0EC675AD498AFEEBB6960B3AABE6will result in an IV of0EC675AD498AFEEBB6960B3AABE60000.For AES-GCM then, a 12 byte master salt, e.g.
0EC675AD498AFEEBB6960B3Ashould result in an IV of00000EC675AD498AFEEBB6960B3A0000. Unfortunately libSRTP uses an incorrect IV of0EC675AD498AFEEBB6960B3A00000000, leading to an incorrect session key and salt being derived.