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@icn.siemens.de | mailto:martin.euchner@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@packetizer.com] Sent: Monday, August 12, 2002 7:39 PM To: itu-sg16@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