Flaws in H.235 media encryption
plong at PACKETIZER.COM
Wed Aug 28 09:49:45 EDT 2002
comments inline; not too long; concern #3 of mine isn't really a problem so
I nuked it altogether
> my answers in the usual style included inline below.
> MEU:> [snip] key update is a good practice in those cases, where the key
> has been compromised or is believed having been compromised;
PL:> I don't understand this. How could such a thing happen? How could I
detect that my security has been compromised? Sounds like such a bizarre,
obscure thing that I should never worry about it.
> [snip (A and B sound okay)]
> > Your solution C with a 3-way handshake acknowledging the reception of
> > new key appears as a robust solution.
> PL:> So that we don't have to add another codepoint to the H.245 ASN.1
> syntax tree, I suppose we could require, starting with H.235v3, that
> the slave echo back the encryptionUpdate command for a master-to-slave
> logical channel (the master would never otherwise receive this
> MEU:> ok agreed. We need such a mechanism.
> The synchFlag would act as a transaction id so that the
> master would know which of its encryptionUpdate commands this was in
> response to. The master would ignore the ack's h235Key field.
> MEU:> I can agree to this basically. I'm not fully convinced if it is a
> idea to use the synchFlag as a "transaction id"; mainly for the reason,
> I believe that the dyn. PT is not guaranteed to be unique over a set of
> logical channels (outgoing or incoming).
PL:> Good point. PT is typically but not necessarilly different. Bad idea.
> So you are saying that the encryptionUpdate should also be used as an ACK
> from the slave to the master?
> I can see another alternative assuming the each entity knows the LCNs of
> peer and is able to associate them to the channels (for the originating
> channels that should be true anyway, but also for the reverse channels),
> a) to use the LCN field in the MiscelleaneousCommand,
> b) enhance the encryptionSync with the master/slave CHOICE structure as
PL:> I see three ways to do this. 1. add an OPTIONAL "direction" component
to encryptionSync, like you suggest, 2. define a complete replacement for
encryptionUpdate, e.g,. encryptionUpdateCommand, that contains
encryptionSync and a "direction" component (and is extensible while we're at
it), and 3. add an OPTIONAL "direction" component to the outer level of
MiscellaneousCommand. I like #3 the best but don't know if we will be able
to add something so high up in the H.245 syntax tree to basically fix a bug.
What do you think?
> c) let the master apply his/her LCN for the logical channel in the
> master->slave, let the master apply the slave LCN for the logical channel
> the direction slave-> master
> d) let the slave acknowledge an encryptionUpdate by another
> (acting as encryptionUpdateAck) or preferably use a separate
> encryptionUpdateAck for that purpose,
> e) the slave reflects the received LCN (indicating master or slave choice)
> in the ACK.
PL:> I could go either way about using encryptionUpdate for the Ack or
defining a new command. I guess this is what an Ack would look like:
(The relevant LCN is at the outer level of MiscellaneousCommand, so it's not
shown here.) We need synchFlag because we could theoretically have multiple
outstanding encryptionUpdate commands for the same LCN but each with a new,
different PT. This is a typical exchange using these codepoints:
<- encryptionUpdate(1, 97, AES(sharedSecretKey, sessionKey2), masterToSlave)
<- - - RTP(96, AES(sessionKey1, payload)) - - -
encryptionUpdateAck(1, 97, masterToSlave) ->
<- - - RTP(97, AES(sessionKey2, payload)) - - -
[snip: we agree on adding a "direction" codepoint]
> > 3. When the master sends an encryptionUpdate command, it specifies the
> > new dynamic payload type, or DPT, in the synchFlag field; however,
> > presents problems for a slave-to-master stream because the transmitter
> > otherwise manages its own DPTs.
PL:> Forget this whole PT-conflict thing. It's not a problem. I was somehow
thinking that PTs we like LCNs in that they had to be unique across an EP's
outgoing channels. This is simply not true. Sorry for propagating the
> I think that I/we should write down
> all this in a contribution and fix it, making the method clear, and
> include the stuff in H.235 and highlight the H.245 changes for Mike
> (H.245 editor).
PL:> Yeah, I could help.
PL:> BTW, I just realized that H.235 media privacy conflicts with other
schemes that also manipulate PT. For example, Cisco inserts PT=13 into their
audio streams for a proprietary silence frame (I think this is based on an
expired I-D). Also, RFC2833 multiplexes packets for, e.g., DTMF in the audio
stream based on PT. Since H.235 assumes that the PT would otherwise be the
same throughout a stream, it simply won't work for these and possibly other
upcoming PT-manipulation schemes. We need to consider another media-privacy
mechanism for these cases, e.g., maintain the original PT by saving it in
the RTP payload. Bummer.
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com
More information about the sg16-avd