[VOIPSEC] Incorrect decryption monitoring feature
lee_dilkie at mitel.com
Mon Sep 25 22:32:51 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Randell Jesup wrote:
> "Geoff Devine" <gdevine at cedarpointcom.com> writes:
>> >From a nuts and bolts customer support point of view, you have either
>> "horrible noise reported" or "no talk path/1-way talk path". At least
>> with authentication failures, you have definitive data at the client
>> device as to why you have a "no talk path/1-way talk path" problem and
>> the client device can even take corrective action (like try a reINVITE).
>> "Horrible noise reported" could be from many causes and there is no way
>> the client device can know it is happening and your customer support
>> people won't have a clue how to get to the root cause.
>> In SRTP, the authentication data is only 4 bytes. In PacketCable, we
>> also allow a 2-byte authentication. Even in G.729 applications, I don't
>> think a couple of bytes are going to break the bank.
> Actually, SRTP auth is a variable number of bytes, from 0 to N,
> and the SRTP default n_tag (tag length) is 10 bytes (80 bits) (and the
> minimum for SRTCP is 80 bits). The spec mentions a 32-bit auth tag for
> SRTP for audio as a possibility (sec 7.5 and 9.5), as well as 0 bytes
> (no auth). Any non-default auth value needs to be specified in SDP/etc,
> explicitly or implicitly.
> Your point is good though, though for some applications, any extra bytes
> will break the bank (if for example they traverse a link that 'knows' that
> G.729 is exactly 8kbps payload, and reserve only that bandwidth). There
> are probably other cases as well.
I was referring to the default, 10 byte HMAC. I gotta go read the rfc
again, I didn't know it was a variable field. An additional 10 bytes
on top of a 20 byte payload is pretty severe.
Okay, I see where it specifies the "default n_tag for HMAC-SHA1 SHALL
be 80 bits", which I read as "it is 80 bits". I guess I never realized
that "n_tag" is some sender/receiver agreed upon value. (I mis-parsed
the word "default")
Also, not all VoIP solutions are sip-based.. We don't all have the
same means of dealing with these issues. That said, we've only seen
decryption problems as a result of coding errors and our logs pinpoint
the problem pretty exactly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Voipsec