Subject: RE: proposal for RTP header authentication method / anti-spamming

From: Euchner Martin <[email-masked]>
Date: Tue, 29 Feb 2000 19:52:07 +0100

my impression obtained by looking shortly at the CableLabs Spec (thanks for
providing the pointer) is that CableLabs might address other (i.e. higher)
security requirements than Henning and I have in mind. This however seems to
indicate, that RTP is being used by different applications, in different
scenarios with different security requirements. BTW, I do not know the
reason why CableLabs considered media integrity that important; is this
described somewhere? 
Thus, it seems evident, that RTP cannot and probably does not have to
satisfy them all with the same security mechanism. My guess is, that the
protocol should support the approaches in some basic manner while
maintaining enough degree of flexibility and find some common mechanism (is
this the padding method? or could we agree to something like that?) that
suits all purposes.

As I mentioned in my initial email, H.235 until now has not identified any
security need for provisioning media integrity. We left this issue for
further study and I believe this will stay so for some more time.

People have already concerns about media encryption performance and this
will become even worse when media integrity should be done as well. Please
remember that ITU-T SG 16 uses RTP not only in terminals, where performance
is not that issue but also in large scale voice gateways with thousands of
parallel media streams. Then each CPU cycle counts and unless there is a
real need for integrity, the encryption provided should probably already be
sufficient.

Manipulation on the encrypted media content would probably yield annoying
sounds at the receiver when trying to decode the manipulated data, but this
"denial-of-service" attack could be countered already when using the
proposed integrity check just over the header parts. So I consider media
integrity as a low(er) priority security requirement. I also doubt whether
media integrity is really appropriate just for countering denial-of-service
attacks with sent spam packets: this sounds a bit of over-engineering to me.

On the other hand, throwing away manipulated RTP packets does not result in
a "denial-of-service attack"; although from a user's perspective this might
look so. This is so, as RTP does not provide a guaranteed delivery of data
(because of unreliable UDP) and packets may get dropped anyway somewhere in
network elements.

For your information, I'm preparing already an internet-draft that goes
beyond my initial ideas. I expect it to be ready early next week and you
will get it as soon as it is ready. The paper will take into account media
integrity as an option as well and will describe also means how efficient
media integrity could be achieved without the need for extra CPU-intensive
integrity computation.

Martin
-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 636-46201
| Martin Euchner                 Fax  : +49 89 636-48000
| Siemens AG
| ZT IK 3                        mailto:[email-masked]
|                                Intranet:
http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/
index.html
| Otto-Hahn-Ring 6               Internet: http://www.siemens.de
| D-81730 Muenchen  
| __________________
| Germany     
-----------------------------------------------------------------------

	-----Original Message-----
	From:	Michael Thomas [SMTP:[email-masked]]
	Sent:	Tuesday, February 29, 2000 6:38 PM
	To:	Henning Schulzrinne
	Cc:	Michael Thomas; Euchner Martin; [email-masked]
	Subject:	Re: proposal for RTP header authentication method /
anti-spamming

	Henning Schulzrinne writes:
	 > However, one consideration is that this is needed not just for
audio,
	 > but also for video, in which case running MAC over the whole
packet is
	 > probably a good idea (2 Mb/s may not do the trick there,
particularly
	 > since you don't want to dedicate your whole CPU to this).

	   So, I'm confused: you're saying that the MAC
	   *should* be run over the RTP header + payload?
	   If so, I agree, and that is in fact what the 
	   packetcable spec mandates.

	   It wasn't clear given my cursory reading of their
	   spec whether the MAC was run over the payload or
	   not. Assuming that it is not, the obvious
	   complaint is that it is susceptible to man in
	   the middle attacks which tamper with the
	   payload. While I guess this comes down to how
	   rigorous you want to be, it seems there should
	   be a huge amount of motivation to *not* do the
	   more secure thing. I'm not convinced at all for
	   audio that there is any such motivation, and
	   I'm pretty doubtful about video as well.

		      Mike