[VOIPSEC] Incorrect decryption monitoring feature

[Lee Dilkie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
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.

- -lee




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFFGEsCm1Xa+pwj4RMRAuJKAKDJaEae9NuPNAaorTtgt/0aMDd5DACfcva9
UGuBfN4rDovim/vNR6toX5Q=
=UrUp
-----END PGP SIGNATURE-----