Flaws in H.235 media encryption

[Euchner Martin ICN M SR 3]

Paul,

first of all: thanks to the very good and detailed observations pointing out
some problematic issues with H.235 key update. As I argue below, items #2
and #3 hit a weak point and should be corrected in some fashion and
documented. I consider item #1 less critical (but let's see).
Second: sorry for the long delay, but I was quite busy with other things and
emails...

Generally, I would like to point out that using the replacementFor mechanism
should thwart against all three problems; but please my more detailed
comments and answers below.



With kind regards


Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner at icn.siemens.de
|                                mailto:martin.euchner at ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany
-----------------------------------------------------------------------

 -----Original Message-----
From:   Paul Long [mailto:plong at packetizer.com]
Sent:   Monday, August 12, 2002 7:39 PM
To:     itu-sg16 at echo.jf.intel.com
Cc:     Euchner Martin  ICN M SR 3
Subject:        Flaws in H.235 media encryption

I believe there are fundamental flaws in H.235 media encryption, i.e.,
how long the master waits before transmitting a new payload-type after
distributing the corresponding key, the directional ambiguity of
encryptionUpdate and encryptionUpdateRequest, and conflicts arising
from both the slave and master assigning new dynamic payload types for
slave-to-master streams. These are discussed in detail, below...

1. After distributing a new key via an encryptionUpdate command for a
master-to-slave RTP stream, how long should the master wait before
transmitting packets with the new payload type? The problem is that
packets with the new payload type (and therefore using the new key) may
arrive before the encryptionUpdate command that tells the slave what
payload-type/key pair to expect! There are three solutions as I see it:
    A. The slave discards new packets until the encryptionUpdate
command arrives.
    B. The master uses prior network behavior to predict when the slave
will receive the command and then waits so that packets using the new
payload type will (hopefully) arrive sometime after that. The slave
should still implement A because this prediction is imprecise.
    C. We require a three-way handshake by adding an
encryptionUpdateAck command for master-to-slave streams (would be
redundant for slave-to-master streams). This would be backwards
compatible because existing implementations would simply ignore this
new command which is sent from slave to master.

A and B are local workarounds; C is the ultimate solution. Discarding
packets is especially problematic for video because video compression
schemes rely on inter-packet dependencies. I believe H.233 anticipated
this problem by providing a codepoint in H.245 to define how long the
transmitter must wait before using the new key. H.235 also needs
something to address this problem, preferably C.

MEU:> In general, I agree that this might be a problem. However, in
practice, situation should not be that worse.
First of all, question is, if you really need encryptionUpdate. For what
I've heard so far is, that for secure IPVoiceTelephony, encryptionUpdate can
probably be omitted (but for video the situation may be different).

Basically, the master should always issue a new key timely and leave
sufficient time for the slave to correctly receive the new key and make it
active. Thus, the master should take into account the propagation delay as
well as the processing delay of the peer. Regarding propagation delay, some
information should be gained from evaluation of RTCP reports or from
measuring H.245 round trip delay that should help the master to predict
network behavior. This provides an estimate when at latest to issue the key.
Shouldn't it be possible to assume a certain "safety window" at the master
that compensate for worst-case network behavior? Likewise the slave
maintains its own safety window, and maintains two session keys for a
certain period of time (the old and current key and the new key). Once a
packet is received that was encrypted with a new key, the old key can be
dropped (not quite in fact. Actually, some delayed old encrypted packets may
still arrive, so it would be wise to keep the two keys for some short
period).
This is all part of your solution B. Nevertheless, this is a "best effort"
method that is not guaranteed to work in any situation; e.g., the network
might experience sudden, extreme slow-down for some reason, that delays the
H.245 key management. Thus, the slave has no other possibility than to
discard newly received encrypted packets without having a corresponding key
(solution A). I wouldn't consider practical to temporarily buffer the
encrypted stream until the key becomes available, this would work only for
very short periods in interactive session.

Your solution C with a 3-way handshake acknowledging the reception of the
new key appears as a robust solution.
However, assuming that H.245 is being transported over TCP/IP, there should
be an implicit acknowledge (at the TCP layer) for issued encyptionUpdate.
Couldn't that information be helpful to the master in deciding when to apply
the new key?

Instead of introducing a new handshake, using replacementFor by opening a
new logical channel with a new key and then closing down the former channel
should provide a reliable means for key update. That way, the problem should
be covered.


Regarding H.233 mechanism, I wasn't able to identify such a mechanism as
claimed (I'm not even sure that H.233 features a key update method).

2. H.235 says that "[the slave, acting as] a receiver (or transmitter)
may request a new key [from the master]" and "The master may also
decide asynchronously to distribute new key(s)." However, there is no
codepoint in either the encryptionUpdate or encryptionUpdateRequest
command to indicate whether it refers to a slave-to-master or master-to-
slave RTP stream. The MiscellaneousCommand.logicalChannelNumber field
is no help either because its values are assigned independently by each
transmitter--both EPs may be using the same LCN.

MEU:> It is correct that the key update works in both directions: either the
master distributes a new key or the slave requests a new key from the
master.
I fear that you discovered a valid problem here that deserves some fix. As
you said it is ambiguous for the slave to which LC the encryptionUpdate
actually refers to.
Thus, we will have to consider some solution; e.g., by adding a "direction
flag" in encryptionUpdateRequest.... (apart from some semantical description
that should appear in H.235v3 and IG). Nevertheless, would it help if one
may assume that the allocated logical channel numbers at the peer side are
known? This information should at least be available in principle at the
endpoints from monitoring the OpenLogicalChannel and CloseLogicalChannel
commends.





For example, assume that both EPs are transmitting audio on their
respective LCN 5. The master intends to asynchronously update the key
for its outgoing audio by sending this command to the slave:
    MiscCmd(lCN=5,encrUpdate=(synFlag=200,h235Key=X))
How should the slave interpret this command? Does this refer to the
slave's own, outgoing audio channel or the master's audio channel?
Likewise, if the slave sends MiscCmd(lCN=5,encrUpdateReq=sharedSecret),
how should the master interpret this? Does the slave want the master to
update the key for the slave's audio channel or the master's audio
channel?

As it is, IMO, key resynchs should not be attempted for channels that
have the same LCN; however, that would be difficult for equipment from
the same vendor because, depending on the LCN-assignment scheme, the
same values may always be used.

MEU:> I hope that the solution that we figure out would not prohibit this
case.

Again as above, replacementFor when applied would allow key update without
the identified problem.

3. When the master sends an encryptionUpdate command, it specifies the
new dynamic payload type, or DPT, in the synchFlag field; however, this
presents problems for a slave-to-master stream because the transmitter
otherwise manages its own DPTs. For example, what if the master sends
an encryptionUpdate command for the slave-to-master audio stream,
specifying new DPT, 102, but before the slave receives it, the slave
sends a video OLC with the same DPT--102? How do we resolve this
conflict? Maybe the master should reject the OLC because it knows that
it just assigned that DPT to the audio channel, but what cause should
the master return? cause=masterSlaveConflict? Is this enough for the
slave to figure out what's wrong and retry the OLC with another DPT? We
should define how to resolve these kinds of conflicts, but it would be
really great if we could revamp this whole key-resynch area due to all
of the problems I have described here.

MEU:> I agree that this appears a problem that should be fixed as well. One
potential solution could be that the slave provides a proposed new dynamic
PT for the LC (to be added in EncryptionUpdateRequest).

Paul