comments inline; not too long; concern #3 of mine isn't really a problem so I nuked it altogether
Paul,
my answers in the usual style included inline below.
[snip]
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]
[snip (A and B sound okay)]
Your solution C with a 3-way handshake acknowledging the reception of
the
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 message).
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
good
idea to use the synchFlag as a "transaction id"; mainly for the reason,
that
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?
PL:> Yes.
I can see another alternative assuming the each entity knows the LCNs of
the
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), namely:
a) to use the LCN field in the MiscelleaneousCommand, b) enhance the encryptionSync with the master/slave CHOICE structure as
you
proposed,
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
direction
master->slave, let the master apply the slave LCN for the logical channel
in
the direction slave-> master d) let the slave acknowledge an encryptionUpdate by another
encryptionUpdate
(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: encryptionUpdateAck SEQUENCE { synchFlag INTEGER(0..255), direction EncryptionUpdateDirection, ... }, (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:
slave master <- 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]
- 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.
[snip]
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 confusion.
I think that I/we should write down all this in a contribution and fix it, making the method clear, and
further
include the stuff in H.235 and highlight the H.245 changes for Mike
Nilsson
(H.245 editor).
[snip]
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@lists.intel.com