Subject: [MSEC] Fwd: [AVT] Unicast RTCP back traffic

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 14 Jan 2002 14:57:11 -0500

Let's try again...

--- the forwarded message follows ---

Subject: [AVT] Unicast RTCP back traffic
From: "Marshall Eubanks" <[email-masked]>
To: [email-masked]
Cc: [email-masked], Toerless Eckert <[email-masked]>
Date: Mon, 14 Jan 2002 14:05:14 -0500
List-Id: Audio/Video Transport Working Group <avt.ietf.org>

Hello;

Here is a first cut at the security implications and
a possible fix for 
unicast back traffic for SSM type RTCP. This is obviously
an AVT issue, I am sending it to MSEC as well.

This is also available as a pdf on 
http://www.multicasttech.com/papers/unicast_rtcp_analysis.pdf

Regards
Marshall Eubanks
[email-masked]
---------------------------------

To 	: AVT, MSEC
From 	: T.M. Eubanks
Subject	: Security of Unicast Back Traffic in RTCP
Date	: January 14, 2002

In the standard Any Source Multicast (ASM) model for the
Real Time Control Protocol (RTCP), the ?back traffic? (the
Receiver Reports, or RR?s, the Sender Reports, or SR?s, and
possibly other user defined auxiliary data, all currently
issued by a receiver as part of RTCP) is sent to the source
and all receivers on a multicast group, with the back
traffic bandwidth being  set to a fraction of the total
bandwidth, as determined at each receiver. This model must
change to support Single Source Multicast (SSM), and there
may be ASM or even unicast applications where SSM-like RTCP
back traffic would be desirable [Chesterfield and Ott,
2001].

In the existing ASM RTCP back traffic model, data are
multicast onto a group listened to by the source or sources
and all receivers. For a network that only implements SSM,
this is not possible, and it may not be desirable even for
an ASM enabled network, as SSM only protocols should not
depend on the existence of ASM network capabilities. An
obvious modification of the ASM RTCP model to handle this
situation is to unicast RR and other back traffic to the
source, and then optionally to multicast the data (either in
the form of RR?s, or as summary digests) to the receivers on
a separate SSM group. In many cases, it would be convenient
to separate the functions of the SSM source and the SSM RTCP
server, and thus to send the unicast RTCP back traffic to an
arbitrary Internet address. I will call the general case of
unicast back traffic to an arbitrary location ?SSM-like?
back traffic.

The Problem

The existence of unicast SSM-like back traffic presents a
possibly serious security problem. If any receiver were to
source an arbitrarily high rate of back traffic, then local
resources could be overwhelmed. In addition, if every
receiver were to source an arbitrarily high rate of back
traffic, then the SSM RTCP report server could be
overwhelmed. Even if receiver back traffic were limited to a
low level for each receiver (say by specifying a limit to
the rate of receiver back traffic), then it will still be
possible to create problems by directing the back traffic to
a different IP address. In fact, a large flow of SSM like
RTCP back traffic would constitute a pre-made Distributed
Denial of Service (DDOS) attack if the traffic could be
redirected by an attacker. This attack is called ?packet
bombing? in Chesterfield and Ott [2001]. 

For this security analysis, I assume that the attacker can
spoof IP addresses and insert traffic in such a fashion that
Reverse Path Forwarding (RPF) and other possible checks of
the integrity of the IP routing are passed. (These checks
are an important line of defense, but they cannot be the
only defense as they can be compromised almost trivially in
certain situations, for example for a multicast source on a
large LAN with an exploited host.) I also assume that the
attacker can become a legitimate member of the group, and
thus has access to any keys or other cryptographic
information available to group members. This of course makes
the authentication problem much harder. For example, it
means that simple symmetric key encryption of the RTCP
traffic, or even of the underlying RTP traffic, as is
suggested in Chesterfield and Ott [2001], will not improve
the security of the SSM-like back traffic, as it must be
assumed that the attacker will possess the keys. 

I will assume that the basic means of authentication of back
traffic direction will be through cryptographic hash
functions, such as MD-5 or SHA-1, coupled with public-key
cryptography. These functions are described in detail in
Schneier [1996]. 

In Chesterfield and Ott [2001], the basic means of
protecting against using the back traffic for denial of
service attacks is to only send back traffic to the source,
and to verify the source by verifying the Session
Description Protocol (SDP) message announcing the source.
There are several objections to this procedure :

1.) The source may not be the appropriate place to deal with
the back traffic. The source may not even be reachable by
unicast from the receivers, as is the case with certain
means of distributing IP data by satellite. Conversely,
there may be multiple sources and it may be desirable to
squelch the back traffic to most of the sources, while still
sending it to others.

2.)  This does not solve the security problem. I may be able
to perform a denial of service on the source by spoofing the
control traffic coming from the source, even if the source
was originally authenticated. (For example, I could increase
the amount of back traffic to a point beyond the capacity of
the source to handle.)

This is recognized by Chesterfield and Ott [2001], who state
as requirements that

      - The information providing the unicast feedback
address
      needs to be authenticated as being from a trusted
source. 
		
      - Data integrity of the RTCP traffic from the source,
particularly
      RSI + LJS packets is also required.

but without stating the means for achieving this. 

CISCO?s IPTV currently sends back unicast RTCP traffic back
upon request. A new APP packet is defined and reports can
only be sent to the source. This packet is protected against
change by signing it with an MD5 hash [Toerless Eckert,
personal communication]. Since every receiver presumably has
access to the shared secret, it is hard to see how this
protocol can stop spoofing of the APP messages, independent
of the cryptographic weakness of the MD5 hash.

Of course, there may be multicast applications where there
is tight communication between sources and receivers, such
that each receiver could have a unique shared secret. This
is not an adequate solution, however, in the context of the
current multicast service model.
Another solution (suggested by Bill Fenner) is to include
the back traffic information in the SDP file, which could
then be subject to authentication. The problem I see with
this is that it makes it impossible to change the back
traffic model once it is set up (many applications/users
store SDP information for long periods of time) and it also
complicates the SDP model. SDP information can be sent now
by SAP, by http or by e-mail. Only http could easily be
changed at present to support the new authentication.

A Protocol for Authenticating Back Traffic Requests

In my opinion, authentication of back traffic requests
requires more infrastructure than is available in
Chesterfield and Ott [2001]. Here, I set forth what I see is
one means of performing this authentication.

The new protocol involves getting a public key for the
source, presumably from a Certificate Authority (related
sources could share private keys and announce the same
public one). (The SDP protocol could be amended to
optionally request this.) A new RTCP message, the Report
Direction Message (RDM), is required.

Then

1.) The source sends RDM?s containing 

	the IP address for the source traffic
	the IP address for the back traffic 
the group (or SSM channel) address
	the desired bandwidth for the traffic (the receiver
bandwidth of Chesterfield and Ott) and
the timestamp of the RDM 

2.) The RDM is signed with a cryptographic hash covering all
of the items in # 1 above. 

3.) The cryptographic hash is encrypted with the private key
of the source. The corresponding public key could be found,
e.g. from a Certificate Authority for the source.
This signature, plus the cryptographic hash, is included in
the RDM and multicast to the group.

4.) The RDM is optionally encrypted.

5.) The RDM is sent to the group members as part of  the
RTCP traffic from the sender.

6.) Each receiver verifies the RDM and uses it to direct the
flow of its RTCP back traffic. This includes decryption if
necessary, verifying that the cryptographic hash is correct,
decryption of the RDM signature using the public key of the
source, verifying that the IP address of the source matches
the IP address of the incoming SSM RTP traffic, verifying
that the correct group address is present, and the timestamp
is in the recent past.

In many situations RDM?s need not change for long periods of
time. In that case, the RDM may be verified by simply
checking the cryptographic hash. If the RDM does not change
the direction or the rate of the back traffic, there is no
reason to authenticate it further.

7.) Optionally, the receiver uses information from the
received RDM to provide integrity checks in its back
traffic. The most secure version of this would be to hash
the return RR with some information being sent directly on
the multicast group, which would verify that the receiver
was actually receiving the multicast data.

Also, there needs to be an upper limit to the amount of RTCP
traffic a receiver may source, of order 1 message per
second, as there is no reason to allow an arbitrarily large
amount of back traffic from any specific receiver.

Possible attacks on this protocol include :

1.) The conflict attack. If I can take a valid RPM message
from the source, modify information (say the IP address of
the RTCP server) and then find a variant of the compromised
message that has the same cryptographic hash as the original
RPM message, then the receiver has no way of knowing that
the message has been corrupted, as this message will give
the same public key signature as the original. This is why
it is necessary to digitally sign the RDM message, as
otherwise the attacker could simply modify the RDM as
desired, and generate a new cryptographic hash for the new
message.

It is reasonable to assume that MD5 is subject to conflict
attacks [Dobbertin, 1996], which is presumably why the IESG
has ruled its use out for new protocols. It is often stated
that the keyed HMAC-MD5 extension of MD5 [RFC2403, 1998] is
still secure. However, this is clearly not the case for this
protocol. The additional security for HMAC-MD5 comes from
the use of a key. Since, in this case, the attacker must be
presumed to know the key (which must be shared with the
entire multicast group), the HMAC-MD5 hash could be
compromised in roughly the same time as an unprotected MD5
hash.

2.) The birthday attack. This is not much of a worry. The
SHA-1 algorithm produces a 160 bit hash function. The number
of messages from the same authority that would have to be
searched to have a 50% chance of finding a pair of messages
producing the same hash function is thus about 2^80. If
there were 1 Giga-RPM messages produced per second from one
authority,
it would take 38 million years to find such a pair.

3.) The replay attack. If I capture a valid RDM message, I
can replay it. The utility of this is limited by including
the group and source address in the RDM hash (this makes it
impossible to send the traffic from a very populated group
to the SSM RTCP server for a much lower bandwidth group). If
a (S,G) is being reused by a sloppy source, an attack would
be possible by reusing a RDM from a high bandwidth
application for a lower bandwidth one. The best way to
prevent this would be to include a timestamp, and only allow
RDM?s to be valid for a limit period (say 180 seconds).

Conclusions

I see no way to authenticate RDM type information for large
public SSM sessions without using public key cryptography.
This is much slower than symmetric key cryptography, which
may be a problem for this protocol. On the other hand, it is
only necessary to protect an RDM for the duration of its
validity, and one key verification per minute (which can be
done entirely at the receiver once the public key for the
source is obtained) does not sound especially onerous. This
rate can be kept even lower if, as is reasonable for many
applications, the contents of the RDM message are not
changed for long periods of time.

One specific conclusion I reached is that HMAC-MD5 for this
application is to be avoided. I recommend that SHA-1 be used
instead.

This protocol imposes a fair amount of extra complexity into
the SSM service model. The response of some application
developers may be not to make use of back traffic
authentication. In that case, a reasonable question is
whether multicast is better served by simply not sending any
RTCP back traffic at all, or whether RTCP should include a
low bandwidth default for back traffic information to the
source (under the assumption that extremely large groups
could afford to pay for the extra complexity of
authentication if the back traffic bandwidth became
problematic). If the default were to unicast one message to
the source every 50 seconds in the absence of valid
authentication, then (assuming that the message were 500
bytes), then it would take 700 group members to saturate a
dial-up connection, and several thousand to saturate a
typical DSL connection. Whether this is a reasonable risk is
open to debate.

References

[Dobbertin, 1996] The Status of MD5 after a Recent Attack,
Hans Dobbbertin, CryptoBytes, Vol. 2, 1-5, 1996.

[Chesterfield and Ott, 2001] RTCP Extension for Single
Source Multicast Sessions with  Unicast RTCP feedback,
Julian Chesterfield and Joerg Ott,
draft-chesterfield-avt-rtcpssm-02.txt, 2001.

[RFC2104, 1997] HMAC: Keyed-Hashing for Message
Authentication, H. Krawczyk,  M. Bellare, and R. Canetti,
IETF Request for Comments: 2104, 1997.

[RFC2403, 1998] The Use of HMAC-MD5-96 within ESP and AH,
C. Madson and R. Glenn, IETF Request for Comments: 2403,
1998.

[Schneier, 1996] Applied Cryptography, Bruce Schneier, J.
Wiley, 1996.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt