- sg16-avd - lists.packetizer.com

Re: [Security] Enhancements to H.233 and H.234
by Even, Roni 18 Sep '02

18 Sep '02

Martin, I think that H.234 did not give values was because when written it only defined 512bit DH since it was for DES. Patrick suggests adding AES and after discussing with him we will add the reference to RFC 1412 as in H.235 Roni > -----Original Message----- > From: Euchner Martin ICN M SR 3 [mailto:Martin.Euchner@icn.siemens.de] > Sent: Tuesday, September 17, 2002 1:49 PM > To: 'Even, Roni'; ITU-SG16(a)echo.jf.INTEL.COM; Euchner Martin > ICN M SR 3 > Subject: RE: [Security] Enhancements to H.233 and H.234 > > > Roni, > > regarding recommended DH parameters, H.234 apparently follows > a different > philosophy than H.235: > > H.234 does not recommend any particular DH set. Any DH-set > should work as > long as the parameters are chosen with care. > On the other hand, H.235 recommends certain sets of DH > parameters (taken > from RFC2412). H.235 also allows to use arbitrary (i.e. non > standardized) > DH-parameters if there is a need for. > > Now I do not know why H.234 did not recommend any particular > set. I can only > speculate: perhaps it was decided to leave that issue to the > implementation. > Or such agreed parameters were simply not available in those > former days. > Anyway, this makes the ITU recommendation pretty vague and introduces > potential interoperability problems. > > H.235 defines the recommended DH-values in order to yield a consistent > security level among key management and media security taking > into account > the media encryption algorithms and also exportability issues. It was > further recognized that using the well-defined DH parameter aids in > interoperability and simplifies implementations. > > One good question that we are touching is: > Should we leave H.234 in the same spirit as the document is/was? > Or should we improve and add more recommendations such as suggested > DH-parameters and some more text? > > I can see arguments for either way... > > > > 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: Even, Roni [mailto:roni.even@POLYCOM.CO.IL] > Sent: Tuesday, September 17, 2002 8:11 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: [Security] Enhancements to H.233 and H.234 > > Patrick, > I still do not understand number 1 since this tag is in the > context of h.233 > and should be specified like that. > As for the prime number look at the RFC 2412. H.235 refer to > it since it > includes verified prime numbers for 1024 and 1536 and I > suggest we have the > same recommendation as H.235. Maybe you should consult with > Martin Euchner > Regards > Roni > > > -----Original Message----- > > From: Patrick Luthi [mailto:patrick.luthi@tandberg.no] > > Sent: Tuesday, September 17, 2002 12:59 AM > > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > > Subject: RE: [Security] Enhancements to H.233 and H.234 > > > > > > Roni, > > > > See my answers in-line! > > > > Regards, > > > > Patrick > > > > At 16:03 9/12/2002 +0300, Even, Roni wrote: > > >Patrick, > > >I looked at the contributions and have some comments. > > > > > >1. In H.233 why the new tag class, why don't you use 11 as > > the rest of H.233 > > >messages. > > > > We used 00 because it defines the universal tag class (11 > > being context > > specific), and we thought that SE_NULL, as data type null > > message, would > > best belong to that class. This makes it consistent with ASN.1. > > > > >2. By adding the new encryption algorithm you need a longer > > DH prime. In > > >H.235 they have a table in annex D which is based on > > RFC2412. Do you think > > >we should have the option to recommend the same numbers as > > H.235 does. > > > > H.233 nor H.234 are specifying any Diffie Hellman prime > values and my > > understanding is that it is left to the implementor to choose > > the best > > value. I see your point, and in the interest of interoperability, a > > specified value would help. > > I will think about how to best integrate some text specifying > > prime values > > in H.234. One idea was to add a note in the section about > > Diffie Hellman > > (clause 4/H.234) saying something (inspired by D.7.1/H.235) > like this: > > It is recommended to use a prime value of 512 bits for the > > DES algorithm > > (when exportable security is of concern), 1024 bits for > > Triple DES and AES > > algorithms (when high security is of concern), and 1536 bits > > for Triple DES > > and AES algorithms (when very high security is of concern). > > Would that address your concerns? Any feedback or comments > > are welcomed! > > > > > > >Regards > > >Roni Even > > > > > > > -----Original Message----- > > > > From: Patrick Luthi [mailto:patrick.luthi@TANDBERG.NO] > > > > Sent: Friday, August 30, 2002 1:54 AM > > > > To: ITU-SG16(a)echo.jf.INTEL.COM > > > > Subject: [Security] Enhancements to H.233 and H.234 > > > > > > > > > > > > Dear experts, > > > > > > > > We would like to share with you 2 proposals for enhancements > > > > to H.233 and > > > > H.234 that we are planning to submit to the October > > meeting of SG16. > > > > > > > > Enhancements to H.233: this contribution proposes to add the > > > > Triple Data > > > > Encryption Algorithm (TDEA or triple DES) and the > > Advanced Encryption > > > > Standard (AES) to the list of algorithms in H.233 along with > > > > corrections of > > > > some inconsistencies. > > > > > > > > Enhancements to H.234: this contribution proposes changes to > > > > H.234 to allow > > > > the exchange of asymmetric length of encryption keys. > > > > > > > > Please let me know if you have any suggestions or comments! > > > > The plan would > > > > be to ask for Consent for both recommendations at the > > closing of the > > > > upcoming SG16. > > > > > > > > Best regards, > > > > > > > > Patrick > > > > > > > > _____________________________ > > > > Patrick Luthi > > > > Manager - Technical Standards > > > > Rapporteur (chairman) for the ITU-T multimedia systems, > > terminals and > > > > data-conferencing Experts group (Question 1/16) > > > > TANDBERG > > > > N-1366 Lysaker, Norway > > > > Phone: + 47 67 125 125 > > > > e-mail: patrick.luthi(a)tandberg.no > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

comments on AVD 2253 from Raleigh
by Even, Roni 17 Sep '02

17 Sep '02

Hi, I have some concerns about the changes proposed in this AVD. 1. The AVD adds a new data type called multiplepayloadstream that is intended to allow more then one payload in a stream. According to the ASN.1 you can have different media types in the same logical channel which is not a good practice and would break a lot of implementations. 2. The data type in H.245 open logical channel describe the media type but do not specify the RTP payload format used. There are cases were there is more then one way to build the RTP stream for example in H.263. In the OLC in H2250LogicalChannelParameters there is a RTPPayloadType parameter that describe the RTP payload. If the AVD is used to describe multiple streams there is no way to specify the packetization scheme used. 3. I think that the editor of H.235 will look to see if the proposed AVD allows to specify and change a key for each payload that can be used in the logical channel. I am not an expert on H.235 Thanks Roni Even ********************************************** Roni Even VP Product Planning Polycom Network Systems Tel: +972-3-9251200 Mobile: +972-55-481099 Fax: +972-3-9211571 Email: roni.even(a)polycom.co.il ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

3 2

Re: [Security] Enhancements to H.233 and H.234
by Euchner Martin ICN M SR 3 17 Sep '02

17 Sep '02

Roni, regarding recommended DH parameters, H.234 apparently follows a different philosophy than H.235: H.234 does not recommend any particular DH set. Any DH-set should work as long as the parameters are chosen with care. On the other hand, H.235 recommends certain sets of DH parameters (taken from RFC2412). H.235 also allows to use arbitrary (i.e. non standardized) DH-parameters if there is a need for. Now I do not know why H.234 did not recommend any particular set. I can only speculate: perhaps it was decided to leave that issue to the implementation. Or such agreed parameters were simply not available in those former days. Anyway, this makes the ITU recommendation pretty vague and introduces potential interoperability problems. H.235 defines the recommended DH-values in order to yield a consistent security level among key management and media security taking into account the media encryption algorithms and also exportability issues. It was further recognized that using the well-defined DH parameter aids in interoperability and simplifies implementations. One good question that we are touching is: Should we leave H.234 in the same spirit as the document is/was? Or should we improve and add more recommendations such as suggested DH-parameters and some more text? I can see arguments for either way... 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: Even, Roni [mailto:roni.even@POLYCOM.CO.IL] Sent: Tuesday, September 17, 2002 8:11 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: [Security] Enhancements to H.233 and H.234 Patrick, I still do not understand number 1 since this tag is in the context of h.233 and should be specified like that. As for the prime number look at the RFC 2412. H.235 refer to it since it includes verified prime numbers for 1024 and 1536 and I suggest we have the same recommendation as H.235. Maybe you should consult with Martin Euchner Regards Roni > -----Original Message----- > From: Patrick Luthi [mailto:patrick.luthi@tandberg.no] > Sent: Tuesday, September 17, 2002 12:59 AM > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > Subject: RE: [Security] Enhancements to H.233 and H.234 > > > Roni, > > See my answers in-line! > > Regards, > > Patrick > > At 16:03 9/12/2002 +0300, Even, Roni wrote: > >Patrick, > >I looked at the contributions and have some comments. > > > >1. In H.233 why the new tag class, why don't you use 11 as > the rest of H.233 > >messages. > > We used 00 because it defines the universal tag class (11 > being context > specific), and we thought that SE_NULL, as data type null > message, would > best belong to that class. This makes it consistent with ASN.1. > > >2. By adding the new encryption algorithm you need a longer > DH prime. In > >H.235 they have a table in annex D which is based on > RFC2412. Do you think > >we should have the option to recommend the same numbers as > H.235 does. > > H.233 nor H.234 are specifying any Diffie Hellman prime values and my > understanding is that it is left to the implementor to choose > the best > value. I see your point, and in the interest of interoperability, a > specified value would help. > I will think about how to best integrate some text specifying > prime values > in H.234. One idea was to add a note in the section about > Diffie Hellman > (clause 4/H.234) saying something (inspired by D.7.1/H.235) like this: > It is recommended to use a prime value of 512 bits for the > DES algorithm > (when exportable security is of concern), 1024 bits for > Triple DES and AES > algorithms (when high security is of concern), and 1536 bits > for Triple DES > and AES algorithms (when very high security is of concern). > Would that address your concerns? Any feedback or comments > are welcomed! > > > >Regards > >Roni Even > > > > > -----Original Message----- > > > From: Patrick Luthi [mailto:patrick.luthi@TANDBERG.NO] > > > Sent: Friday, August 30, 2002 1:54 AM > > > To: ITU-SG16(a)echo.jf.INTEL.COM > > > Subject: [Security] Enhancements to H.233 and H.234 > > > > > > > > > Dear experts, > > > > > > We would like to share with you 2 proposals for enhancements > > > to H.233 and > > > H.234 that we are planning to submit to the October > meeting of SG16. > > > > > > Enhancements to H.233: this contribution proposes to add the > > > Triple Data > > > Encryption Algorithm (TDEA or triple DES) and the > Advanced Encryption > > > Standard (AES) to the list of algorithms in H.233 along with > > > corrections of > > > some inconsistencies. > > > > > > Enhancements to H.234: this contribution proposes changes to > > > H.234 to allow > > > the exchange of asymmetric length of encryption keys. > > > > > > Please let me know if you have any suggestions or comments! > > > The plan would > > > be to ask for Consent for both recommendations at the > closing of the > > > upcoming SG16. > > > > > > Best regards, > > > > > > Patrick > > > > > > _____________________________ > > > Patrick Luthi > > > Manager - Technical Standards > > > Rapporteur (chairman) for the ITU-T multimedia systems, > terminals and > > > data-conferencing Experts group (Question 1/16) > > > TANDBERG > > > N-1366 Lysaker, Norway > > > Phone: + 47 67 125 125 > > > e-mail: patrick.luthi(a)tandberg.no > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: [Security] Enhancements to H.233 and H.234
by Even, Roni 17 Sep '02

17 Sep '02

Patrick, I still do not understand number 1 since this tag is in the context of h.233 and should be specified like that. As for the prime number look at the RFC 2412. H.235 refer to it since it includes verified prime numbers for 1024 and 1536 and I suggest we have the same recommendation as H.235. Maybe you should consult with Martin Euchner Regards Roni > -----Original Message----- > From: Patrick Luthi [mailto:patrick.luthi@tandberg.no] > Sent: Tuesday, September 17, 2002 12:59 AM > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > Subject: RE: [Security] Enhancements to H.233 and H.234 > > > Roni, > > See my answers in-line! > > Regards, > > Patrick > > At 16:03 9/12/2002 +0300, Even, Roni wrote: > >Patrick, > >I looked at the contributions and have some comments. > > > >1. In H.233 why the new tag class, why don't you use 11 as > the rest of H.233 > >messages. > > We used 00 because it defines the universal tag class (11 > being context > specific), and we thought that SE_NULL, as data type null > message, would > best belong to that class. This makes it consistent with ASN.1. > > >2. By adding the new encryption algorithm you need a longer > DH prime. In > >H.235 they have a table in annex D which is based on > RFC2412. Do you think > >we should have the option to recommend the same numbers as > H.235 does. > > H.233 nor H.234 are specifying any Diffie Hellman prime values and my > understanding is that it is left to the implementor to choose > the best > value. I see your point, and in the interest of interoperability, a > specified value would help. > I will think about how to best integrate some text specifying > prime values > in H.234. One idea was to add a note in the section about > Diffie Hellman > (clause 4/H.234) saying something (inspired by D.7.1/H.235) like this: > It is recommended to use a prime value of 512 bits for the > DES algorithm > (when exportable security is of concern), 1024 bits for > Triple DES and AES > algorithms (when high security is of concern), and 1536 bits > for Triple DES > and AES algorithms (when very high security is of concern). > Would that address your concerns? Any feedback or comments > are welcomed! > > > >Regards > >Roni Even > > > > > -----Original Message----- > > > From: Patrick Luthi [mailto:patrick.luthi@TANDBERG.NO] > > > Sent: Friday, August 30, 2002 1:54 AM > > > To: ITU-SG16(a)echo.jf.INTEL.COM > > > Subject: [Security] Enhancements to H.233 and H.234 > > > > > > > > > Dear experts, > > > > > > We would like to share with you 2 proposals for enhancements > > > to H.233 and > > > H.234 that we are planning to submit to the October > meeting of SG16. > > > > > > Enhancements to H.233: this contribution proposes to add the > > > Triple Data > > > Encryption Algorithm (TDEA or triple DES) and the > Advanced Encryption > > > Standard (AES) to the list of algorithms in H.233 along with > > > corrections of > > > some inconsistencies. > > > > > > Enhancements to H.234: this contribution proposes changes to > > > H.234 to allow > > > the exchange of asymmetric length of encryption keys. > > > > > > Please let me know if you have any suggestions or comments! > > > The plan would > > > be to ask for Consent for both recommendations at the > closing of the > > > upcoming SG16. > > > > > > Best regards, > > > > > > Patrick > > > > > > _____________________________ > > > Patrick Luthi > > > Manager - Technical Standards > > > Rapporteur (chairman) for the ITU-T multimedia systems, > terminals and > > > data-conferencing Experts group (Question 1/16) > > > TANDBERG > > > N-1366 Lysaker, Norway > > > Phone: + 47 67 125 125 > > > e-mail: patrick.luthi(a)tandberg.no > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: [Security] Enhancements to H.233 and H.234
by Even, Roni 16 Sep '02

16 Sep '02

Patrick, I looked at the contributions and have some comments. 1. In H.233 why the new tag class, why don't you use 11 as the rest of H.233 messages. 2. By adding the new encryption algorithm you need a longer DH prime. In H.235 they have a table in annex D which is based on RFC2412. Do you think we should have the option to recommend the same numbers as H.235 does. Regards Roni Even > -----Original Message----- > From: Patrick Luthi [mailto:patrick.luthi@TANDBERG.NO] > Sent: Friday, August 30, 2002 1:54 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: [Security] Enhancements to H.233 and H.234 > > > Dear experts, > > We would like to share with you 2 proposals for enhancements > to H.233 and > H.234 that we are planning to submit to the October meeting of SG16. > > Enhancements to H.233: this contribution proposes to add the > Triple Data > Encryption Algorithm (TDEA or triple DES) and the Advanced Encryption > Standard (AES) to the list of algorithms in H.233 along with > corrections of > some inconsistencies. > > Enhancements to H.234: this contribution proposes changes to > H.234 to allow > the exchange of asymmetric length of encryption keys. > > Please let me know if you have any suggestions or comments! > The plan would > be to ask for Consent for both recommendations at the closing of the > upcoming SG16. > > Best regards, > > Patrick > > _____________________________ > Patrick Luthi > Manager - Technical Standards > Rapporteur (chairman) for the ITU-T multimedia systems, terminals and > data-conferencing Experts group (Question 1/16) > TANDBERG > N-1366 Lysaker, Norway > Phone: + 47 67 125 125 > e-mail: patrick.luthi(a)tandberg.no > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Re: Encrypting session key
by Euchner Martin ICN M SR 3 13 Sep '02

13 Sep '02

Paul, thanks once more for your review of H.235V3. You may find my answers in the usual style in-lined 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, September 09, 2002 5:25 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Encrypting session key H.235 says, "The session key encryption algorithm is the same as the negotiated media encryption algorithm." At the very least, this of course means that one uses the same cipher; however, there are some important details that this statement overlooks, i.e., mode, IV, salt, and padding. I assume that the guiding principle is to treat the ASN.1 encoded value as much like an RTP payload as possible. MEU:> I'm not certain if that is really a non-stated principle in this case. Mode Does one use the same mode as media and therefore the same block processing for each successive block in the encoded ASN.1 value? MEU:> Yes, that is the intention. See for example the statement in H.235V3 section 8.6.1 "The negotiated encryption algorithms and their modes of operation for the media stream encryption will be used also for secure distribution of the session key. The encryption algorithm for encryption of the media key shall operate in the same chaining mode as the media encryption algorithm". IV For H.235v3, one clearly uses the IV specified in the new type, NewKeySyncMaterial.paramS. MEU:> That's correct. However, what does one do for v2? There doesn't seem to be any way to specify the IV for session-key encryption. MEU:> Don't be afraid that you can't find a direct counterpart for NewKeySyncMaterial.paramS in version 2. H.235 Version2 works slightly differently, namely: H235Key.sharedSecret carries the params as part of the ENCRYPTED{} operation/macro; see also section D.7.2. I would like to note that I should add some text in that section, that describes the v3 NewKeySyncMaterial fields; to be completed.... I suppose one could derive it from the session key similar to how SRTP derives stuff from the master key. For example, IV = session key. Maybe this should go in the IG. MEU:> No, no, no. This has nothing to do with SRTP. We are considering key management here. Everything should be there for signalling the IV. Salt This is a tough one. One could have used the same salt being signaled for media, but it is of course encrypted! Therefore, if the mode for encrypting media is EOFB, which uses a salt value, and one is supposed to use the same "encryption algorithm" for encrypting the session key as encrypting media, what salt value does one use? An implied salt value of all zeros would work, but this is not written down anywhere. MEU:> Paul, your observation is true. At present, v3 provides just a salt for the media part, but does say anything about a salt for the purpose of key distribution. This should indeed be clarified in H.235v3. My proposal is just as simple, namely to state that a "NULL salting key" (i.e. no salting key effectively) shall be used for encryption of the session key and for encryption of the salting key. Thus, with the "NULL salting key" that does not get signaled, the EOFB mode becomes actually the standard OFB mode. This is possible when assuming or ensuring that the session key and the (media) salting key are random; then the ciphertexts are not susceptible to known-plaintext attacks anyway. NewKeySyncMaterial ::= SEQUENCE { generalID Identifier, -- peer terminal ID algorithmOID OBJECT IDENTIFIER, -- encryption algorithm paramS Params, -- IV encryptedSessionKey OCTET STRING, -- encrypted session key encryptedSaltingKey OCTET STRING OPTIONAL, -- encrypted salting key for media ... } Notes: The session key distribution/key update protocol for the EOFB mode would look like A->B: IDa, IV, ENC_MK,IV,0(K), ENC_MK,IV,0(KS). Where IDa is the generalID of the source, IV is the initial value/vector ENC_M,I,0(K) mean EOFB encryption of plaintext K using key M, initial value/vector I and a NULL salting key. KS is the salting key for the media K is plaintext session key. If felt useful, I would like to add such a diagram to H.235v3. Padding This is the toughest to translate from media to session-key encryption. This is the overall H.235 statement as to what kind of padding to perform on media: "Two methods are available to handle packets whose payload is not a multiple of blocks: 1) Ciphertext Stealing for ECB and CBC; Zero pad for CFB and EOFB. 2) Padding in the manner prescribed by [RTP] (Section 5.1)." Since a session key isn't an RTP packet, we can eliminate #2. Therefore, #1 says to use zero padding for EOFB and ciphertext stealing for CBC. Is that how we handle padding when encrypting the session key? MEU:> I guess that your issue mostly is due to some missing information (that might be stated somewhere in the text, if you want). For DES and AES128 there is no need for padding as the key always fits into one or a few blocks. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

None
by 이심현 13 Sep '02

13 Sep '02

OK

1 0

Re: Required/recommended ciphers in H.235?
by Euchner Martin ICN M SR 3 12 Sep '02

12 Sep '02

Hi Paul, thanks for your review of H.235v3. Let me try to answer your questions 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, September 09, 2002 6:16 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Required/recommended ciphers in H.235? Can anyone harmonize the various requirements/recommendations in H.235 regarding which ciphers and modes to support? I've tried to summarize the various relevant passages from H.235, below. This text is from the H.235v3 draft but v2 is similarly unclear. MEU:> I hope that my answers do not let you continue believing that H.235 is unclear in these areas. Regardless of what H.235 says, is there any concensus about which to actually support, e.g., DES/CBC as the base-level encryption scheme plus AES/EOFB on a forward- looking basis? MEU:> We have a definite agreement for H.235v2 what to support. For version 3, the add-ons (AES, EOFB) are a proposal on the table and are subject for discussion and change, yet we are currently in the phase to achieve consensus, until H.235v3 becomes stable. I agree that the situation appears a bit complicated for the following reasons: H.235v2 defines just the 3 encryption algorithms: DES, RC2 and 3DES. DES is a shall implement, while 3DES, RC2 are may implement, where DES and RC2 are considered as exportable ciphers (in certain countries). H.235v3 adds AES as another may implement cipher. The encryption cipher does not say which encryption mode (such as ECB, CBC etc) the cipher should actually operate in. Thus, the issue of the mode is a separate one. Note, that the operation mode is not crucial to exportability considerations. Simply speaking, H.235v2 only defines CBC encryption mode for each cipher. H.235v3 adds the EOFB mode as a further option (may). Due to the fact that there is just a single OID available, there is a distinct OID value assigned for each defined combination cipher + mode. The baseline security profile (D.6.1) says, "H.323 entities when deploying the voice encryption security profile shall implement 56-bit DES as the default encryption algorithm; they may implement 128-bit AES or 168-bit Triple-DES while they may implement exportable encryption using 56-bit RC2-compatible." This passage does not say whether to use CBC or EOFB mode. It either means CBC because it is carried forward from H.235v2 or it is not mode-specific. Shall DES May AES May 3DES May RC2 MEU:> This is correct and fully intentional. This referenced statement addresses the ciphers but not the modes. As I explained above, H.235v2 is not mode specific, but V3 further extends the capabilities without changing backwards compatibility. Text specific to Fast Connect (8.6.1) says, 'According to Annex D, these capabilities should indicate support for 128-bit AES-CBC (OID - "Z3"), 56-bit RC2-compatible-CBC (OID - "X"), should indicate support for 56-bit DES-CBC (OID - "Y") and may indicate support for 168-bit Triple-DES-CBC (OID - "Z"), 56-bit DES-EOFB (OID - "Y1"), or 168-bit Triple-DES-EOFB (OID - "Z1"), RC2-compatible-EOFB (OID - "X1"), DES- EOFB (OID - "Y1") or AES-EOFB (OID - "Z2").' Should AES CBC Should RC2 CBC Should DES CBC May 3DES CBC May DES EOFB May 3DES EOFB May RC2 EOFB May DES EOFB (duplicate!?) May AES EOFB MEU:> The duplicate is indeed an editorial copy & paste mistake. Thanks for pointing this out. Just remove either duplicate. This is a complete set that allows to run each cipher in CBC or in EOFB mode. As editor, I'm a little bit concerned about the variety that arises (see also my contribution AVD-2243 "Considerations for discussion on fast start-based security capability negotiation"). I would love to hear opinions if all that variety is actually needed or if the EOFB mode is needed just for a particular (set of, which?) algorithm(s); e.g. EOFB only for AES??? I could imagine that some less frequently implemented ciphers might not need the EOFB mode. This is an area where I'm not certain if there is conscious consensus yet. Comments are highly appreciated! The voice encryption security profile (D.6.1.2) says, "In addition to the CBC-encryption mode, H.323 entities may implement the EOFB encryption mode." Does this mean that H.323 entities _should_ support CBC but may support EOFB? Should CBC May EOFB MEU:> yes correct, that is the idea. The voice encryption security profile (D.7) also says, "The audio payload is encrypted using the negotiated encryption algorithm ("X", "Y", "Z3" or "Z") operating in CBC mode according to the procedures described in section 11 and annex B of H.235 and the ciphertext padding methods of Appendix I.1/H.235. The audio payload may be encrypted using the negotiated encryption algorithm ("X1", "Y1", "Z1" or "Z2") operating in a stream cipher mode (EOFB)." However, I don't know what "is" means, as in, "The audio payload is encrypted using..." IOW, does it mean "shall," "should" or is it not prescriptive at all? Is RC2 CBC Is DES CBC Is AES CBC Is 3DES CBC May RC2 EOFB May DES EOFB May 3DES EOFB May AES EOFB MEU:> Good point. I agree that the "is" is bad language here. It was meant to mean "shall". I will file a change request if agreed. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

More Mail List Troubles? Please Ignore This Test Message.
by Meyer, Greg W 11 Sep '02

11 Sep '02

Hello: We've seen some anomolies again in the ITU-SG16 mail list and this message is a test to see if it's working OK. Greg Meyer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Contributions to the SG16 meeting (15-25 October 2002)
by OKUBO Sakae 10 Sep '02

10 Sep '02

Dear Q.D,F,G,2-5/16 experts, I have created a new directory at the avc-site: ftp://standard.pictel.com/avc-site/0210_Gen or http://standard.pictel.com/ftp/avc-site/0210_Gen This is for the documents input to and output from the SG16 October meeting in Geneva. Please post your delayed contributions and TDs at the following place and make an announcement at the reflector <itu-sg16(a)lists.intel.com>: ftp://standard.pictel.com/avc-site/Incoming Please note that the files stored there are those provided voluntarily by the contributors for early review of the input/output documents by the experts. Since the SG16 meeting is an official ITU-T meeting and managed by TSB, you must send your documents to TSB-EDH. The meeting documents will be made available at the ITU TIES site for ITU-T members. The PictureTel site is NOT intended for mirroring the ITU TIES site, it is functioning to assist the study of experts. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Encrypting session key
by Paul Long 09 Sep '02

09 Sep '02

comments inline > Paul- > I think the H.235 statement is a mistake. It makes much more sense to treat the > update > just like the initial key distribution: I wasn't distinguishing between the initial and subsequent key distributions--my questions apply equally to them both because they ultimately use the same type, EncryptionSync, and presumably posses the same semantics. > use the negotiated shared secret, the > indicated > algorithm (which could be any algorithm supported by the parties), and the > provided > initialization vector(s), if any. In any case, all this is contained in the > H235Key.sharedSecret, isn't it? (Take a look at the ENCRYPTED() macro.) No, H235Key.sharedSecret is apparently lacking in this regard. See below. > The > statement > you quote would just require that the algorithmOID be the same as the media > encryption > algorithm - and even that is not necessarily a good idea, I think, so perhaps we > should > ask the editor to change it. I see no reason to use a different encryption algorithm for media privacy and private key distribution. I'd like this to be as simple as possible. Therefore, for key distribution, we should try to exploit the existing media-privacy codepoints and semantics wherever possible. > I've made a couple of specific comments in your message, below. > -Bob > ---------------------------------------------------- > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > Paul Long wrote: > > > > H.235 says, "The session key encryption algorithm is the same as the > > negotiated media encryption algorithm." At the very least, this of > > course means that one uses the same cipher; however, there are some > > important details that this statement overlooks, i.e., mode, IV, salt, > > and padding. I assume that the guiding principle is to treat the ASN.1 > > encoded value as much like an RTP payload as possible. > > > > Mode > > Does one use the same mode as media and therefore the same block > > processing for each successive block in the encoded ASN.1 value? > > The mode should be part of the algorithm OID in ENCRYPTED(). Yeah, I know. I was just wanting to make sure that one uses the indicated mode in exactly the same way as for media. I guess you are saying that the answer is, yes. > > IV > > For H.235v3, one clearly uses the IV specified in the new type, > > NewKeySyncMaterial.paramS. However, what does one do for v2? There > > doesn't seem to be any way to specify the IV for session-key > > encryption. I suppose one could derive it from the session key similar > > to how SRTP derives stuff from the master key. For example, IV = > > session key. Maybe this should go in the IG. > > This is defined in ENCRYPTED().paramS: > > H235Key ::=CHOICE -- this is used with the H.245 "h235Key" field > { > secureChannel KeyMaterial, > sharedSecret ENCRYPTED {EncodedKeySyncMaterial}, > certProtectedKey SIGNED { EncodedKeySignedMaterial }, > ... > } > > ENCRYPTED { ToBeEncrypted } ::= SEQUENCE { > algorithmOID OBJECT IDENTIFIER, > paramS Params, -- any "runtime" parameters > encryptedData OCTET STRING > } ( CONSTRAINED BY { -- Encrypt or Decrypt -- ToBeEncrypted } ) Okay, I see now. I just wish it were not defined as part of an optional profile. D.7.2: "paramS: set to the initial value. iv8 holds a random 64-bit block bit pattern that the initiator generates. This field is not used for the CBC mode and is set to NULL." Hmmm... CBC uses an IV, so how does one signal it if not via paramS? > > Salt > > This is a tough one. One could have used the same salt being signaled > > for media, but it is of course encrypted! Therefore, if the mode for > > encrypting media is EOFB, which uses a salt value, and one is supposed > > to use the same "encryption algorithm" for encrypting the session key > > as encrypting media, what salt value does one use? An implied salt > > value of all zeros would work, but this is not written down anywhere. > > I'd suggest that we could add salt to the Params structure. But it would be passed in the clear, wouldn't it? Seems like we're going to have to derive it somehow. For example, assume that the master salt has the same value as the master key. That's better than passing it in the clear or using a static value, isn't it? > > Padding > > This is the toughest to translate from media to session-key encryption. > > This is the overall H.235 statement as to what kind of padding to > > perform on media: "Two methods are available to handle packets whose > > payload is not a multiple of blocks: 1) Ciphertext Stealing for ECB and > > CBC; Zero pad for CFB and EOFB. 2) Padding in the manner prescribed by > > [RTP] (Section 5.1)." Since a session key isn't an RTP packet, we can > > eliminate #2. Therefore, #1 says to use zero padding for EOFB and > > ciphertext stealing for CBC. Is that how we handle padding when > > encrypting the session key? > > I'd suggest that padding method be part of the algorithm OID, and that we > shouldn't tie this to the media stream. If we need to specify it explicitly, > then we should add it to Params. How about just always use zero padding when encrypting session encryption material? Is there any reason at all to use something more flexible? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Encrypting session key
by Paul Long 09 Sep '02

09 Sep '02

H.235 says, "The session key encryption algorithm is the same as the negotiated media encryption algorithm." At the very least, this of course means that one uses the same cipher; however, there are some important details that this statement overlooks, i.e., mode, IV, salt, and padding. I assume that the guiding principle is to treat the ASN.1 encoded value as much like an RTP payload as possible. Mode Does one use the same mode as media and therefore the same block processing for each successive block in the encoded ASN.1 value? IV For H.235v3, one clearly uses the IV specified in the new type, NewKeySyncMaterial.paramS. However, what does one do for v2? There doesn't seem to be any way to specify the IV for session-key encryption. I suppose one could derive it from the session key similar to how SRTP derives stuff from the master key. For example, IV = session key. Maybe this should go in the IG. Salt This is a tough one. One could have used the same salt being signaled for media, but it is of course encrypted! Therefore, if the mode for encrypting media is EOFB, which uses a salt value, and one is supposed to use the same "encryption algorithm" for encrypting the session key as encrypting media, what salt value does one use? An implied salt value of all zeros would work, but this is not written down anywhere. Padding This is the toughest to translate from media to session-key encryption. This is the overall H.235 statement as to what kind of padding to perform on media: "Two methods are available to handle packets whose payload is not a multiple of blocks: 1) Ciphertext Stealing for ECB and CBC; Zero pad for CFB and EOFB. 2) Padding in the manner prescribed by [RTP] (Section 5.1)." Since a session key isn't an RTP packet, we can eliminate #2. Therefore, #1 says to use zero padding for EOFB and ciphertext stealing for CBC. Is that how we handle padding when encrypting the session key? Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Required/recommended ciphers in H.235?
by Paul Long 09 Sep '02

09 Sep '02

Can anyone harmonize the various requirements/recommendations in H.235 regarding which ciphers and modes to support? I've tried to summarize the various relevant passages from H.235, below. This text is from the H.235v3 draft but v2 is similarly unclear. Regardless of what H.235 says, is there any concensus about which to actually support, e.g., DES/CBC as the base-level encryption scheme plus AES/EOFB on a forward- looking basis? The baseline security profile (D.6.1) says, "H.323 entities when deploying the voice encryption security profile shall implement 56-bit DES as the default encryption algorithm; they may implement 128-bit AES or 168-bit Triple-DES while they may implement exportable encryption using 56-bit RC2-compatible." This passage does not say whether to use CBC or EOFB mode. It either means CBC because it is carried forward from H.235v2 or it is not mode-specific. Shall DES May AES May 3DES May RC2 Text specific to Fast Connect (8.6.1) says, 'According to Annex D, these capabilities should indicate support for 128-bit AES-CBC (OID "Z3"), 56-bit RC2-compatible-CBC (OID "X"), should indicate support for 56-bit DES-CBC (OID "Y") and may indicate support for 168-bit Triple-DES-CBC (OID "Z"), 56-bit DES-EOFB (OID "Y1"), or 168-bit Triple-DES-EOFB (OID "Z1"), RC2-compatible-EOFB (OID "X1"), DES- EOFB (OID "Y1") or AES-EOFB (OID "Z2").' Should AES CBC Should RC2 CBC Should DES CBC May 3DES CBC May DES EOFB May 3DES EOFB May RC2 EOFB May DES EOFB (duplicate!?) May AES EOFB The voice encryption security profile (D.6.1.2) says, "In addition to the CBC-encryption mode, H.323 entities may implement the EOFB encryption mode." Does this mean that H.323 entities _should_ support CBC but may support EOFB? Should CBC May EOFB The voice encryption security profile (D.7) also says, "The audio payload is encrypted using the negotiated encryption algorithm ("X", "Y", "Z3" or "Z") operating in CBC mode according to the procedures described in section 11 and annex B of H.235 and the ciphertext padding methods of Appendix I.1/H.235. The audio payload may be encrypted using the negotiated encryption algorithm ("X1", "Y1", "Z1" or "Z2") operating in a stream cipher mode (EOFB)." However, I dont know what "is" means, as in, "The audio payload is encrypted using..." IOW, does it mean "shall," "should" or is it not prescriptive at all? Is RC2 CBC Is DES CBC Is AES CBC Is 3DES CBC May RC2 EOFB May DES EOFB May 3DES EOFB May AES EOFB Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Raleigh meeting report AVD-2259
by OKUBO Sakae 04 Sep '02

04 Sep '02

Dear SG16 experts, The subject document has been uploaded as follows: http://standard.pictel.com/ftp/avc-site/0208_Ral/AVD-2259.zip -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Hotel Reservations - October
by Paul E. Jones 30 Aug '02

30 Aug '02

Dear Experts, If you have not already made hotel reservations for the October meeting in Geneva, I would advise that you do so as soon as possible. Apparently, hotel space is extremely limited, particularly during the second week of the meeting. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

[Security] Enhancements to H.233 and H.234
by Patrick Luthi 29 Aug '02

29 Aug '02

Dear experts, We would like to share with you 2 proposals for enhancements to H.233 and H.234 that we are planning to submit to the October meeting of SG16. Enhancements to H.233: this contribution proposes to add the Triple Data Encryption Algorithm (TDEA or triple DES) and the Advanced Encryption Standard (AES) to the list of algorithms in H.233 along with corrections of some inconsistencies. Enhancements to H.234: this contribution proposes changes to H.234 to allow the exchange of asymmetric length of encryption keys. Please let me know if you have any suggestions or comments! The plan would be to ask for Consent for both recommendations at the closing of the upcoming SG16. Best regards, Patrick _____________________________ Patrick Luthi Manager - Technical Standards Rapporteur (chairman) for the ITU-T multimedia systems, terminals and data-conferencing Experts group (Question 1/16) TANDBERG N-1366 Lysaker, Norway Phone: + 47 67 125 125 e-mail: patrick.luthi(a)tandberg.no ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Flaws in H.235 media encryption
by Euchner Martin ICN M SR 3 28 Aug '02

28 Aug '02

Paul, my answers in the usual style included inline 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: Thursday, August 22, 2002 3:58 AM To: ITU-SG16(a)echo.jf.INTEL.COM Cc: Euchner Martin ICN M SR 3 Subject: Re: Flaws in H.235 media encryption comments inline (and boy are they long this time) > 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. [snip] > > -----Original Message----- > From: Paul Long [mailto:plong@packetizer.com] > Sent: Monday, August 12, 2002 7:39 PM > To: itu-sg16(a)echo.jf.intel.com > Cc: Euchner Martin ICN M SR 3 > Subject: Flaws in H.235 media encryption > [snip] > 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). PL:> But the Voice Encryption Security Profile requires re-key: D.7.2/H.235v2: "The key refresh rate shall be such that no more than 2 [^]32 blocks are encrypted using the same key." Besides this requirement, I just thought that re-keying was good practice in general, but I'm new to the field of security. What is best practice for this and what are the considerations? Hmmm... doing some quick calculations, it looks like it could take at least a few years to reach 2^32 blocks. Is your point that, since most calls don't last months or years, it's probably okay not to ever re-key? MEU:> To be precise, Annex D requires a key refresh at some point in time (upper bound for expired key as given in your citation), but does not actually mandate the exact method (it is a MAY) and other methods than described (like replacementFor, close/reopen) could be applied as well. Nevertheless, key update is a good practice in those cases, where the key has been compromised or is believed having been compromised; this could happen far before the key actually expires. Such situations might arise anytime but clearly are an issue of security policy how to handle. As you assumed, key update for voice would rarely occur under realistic situations as far as voice telephony is concerned. Annex E.2 conveys a tiny footnote giving an example how long a key may be used for a particular voice codec: "key-update for secure G.711 speech coding should occur latest after transmission of 2**30 64-bit blocks, that's more than 12 days of ongoing conversation.". As it becomes apparent, that turns out to be a pretty long time for ongoing secure conversation; and thus, the key update method probably is not implemented as a high priority feature. Let me note however, that the key refresh period depends on the codec and the amount of transmitted traffic, thus, the situation for video may be completely different than for G.711 voice. [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). 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 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, 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. Otherwise, we should add an encryptionUpdateAck component to the type CHOICE of the MiscellaneousCommand type. It would look like this: encryptionUpdateAck SEQUENCE { synchFlag INTEGER(0..255), ... }, MEU:> Using a separate ACK command appears clean and understandable for everyone and avoids the overloaded use of encryptionUpdate. Thus, for the sake of clarity, if would prefer such a solution unless H.245 blow-up is a concern. > 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? PL:> Remember that TCP is a streaming protocol, so I doubt whether there is any way to know whether a particular sequence of bytes, e.g., a TPKT, has been received at the far end. Even if there were, I doubt whether all TCP implementations would provide this mechanism. Therefore, we cannot rely on the transport layer to ack receipt of the new key. Nice try, though. :-) MEU:> ok, I see that my assumption is a bit far fetched. ;-) > 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. PL:> That would sort of work. It also has the benefit of not having to change the RTP payload type for the new logical channel. There are disadvantages, however: 1. H.235 requires the use of encryptionUpdate (11.1/H.235v2: "After receiving an encryptionUpdateRequest, a master shall send out encryptionUpdate."). 2. replacementFor requires a LOT more signaling, i.e., OLC/OLCAck/CLC/CLCAck. 3. Possible (effective) packet loss if the first packet of the new channel arrives before the last packet of the old channel, thereby possibly causing noticeable media artifact or delay. 4. Requires twice the resources temporarilly while the two logical channels overlap, e.g., two sockets. 5. Overall increased complexity. We would basically be trading the lack of synchronicity between the control channel and the media logical channel for the lack of synchronicity between two media logical channels. I vote, no. MEU:> Ok I recognize that you don't like replacementFor procedure for purpose of key update for understandable reasons. So I agree, a better solution is required. > 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). PL:> You are correct--H.233 does not re-key, but it does have an analogous mechanism to update the initialization vector. H.324 added the codepoint, h233IVResponseTime, to H.245 to express how long the transmitter should wait between transmitting a new IV and transmitting frames based on that IV. This is what I was referring to. MEU: correct. That's what I found as well. Still, I believe that the time to wait has to be guessed due to some criteria (e.g. network delay etc). So that solution appears to have similar problems as H.235. > 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). PL:> Yeah, we gotta fix this. Unfortunately, encryptionUpdate does not have a type of its own that we can extend. We would have to extend the EncryptionSync type, but this is used in other contexts where the extensions would have no meaning. MEU:> correct. We could make those extensions optional and allow the use only for the purpose for key update, but otherwise prohibit the use of the key update extensions. The alternative is to add a new codepoint that obsoletes encryptionUpdate. We would define a new direction type, e.g., EncryptionUpdateDirection ::=CHOICE { masterToSlave NULL, slaveToMaster NULL, ... } MEU:> This sounds fine! and add this to the type CHOICE of the MiscellaneousCommand type: encryptionUpdateCommand SEQUENCE { encryptionSync EncryptionSync, direction EncryptionUpdateDirection, ... } MEU:> ok (or have this CHOICE be part of encryptionSync). The request type would be extended thusly: EncryptionUpdateRequest ::=SEQUENCE { keyProtectionMethod KeyProtectionMethod OPTIONAL, ..., direction EncryptionUpdateDirection OPTIONAL, } MEU:> ok; agreed. > 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. PL:> The problem is not that LCNs are not know--they are all indeed know by both sides--but that they are ambiguous. MEU: ok. [snip] > 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. PL:> No, there are four re-key scenarios, and replacementFor would only address the one where the master asynchronously updates the key for a master-to-slave logical channel. Plus, there are the general problems that I pointed out, above, with the replacementFor solution. MEU:> ok let's forget about replacementFor; it was never made actually for key update, so we cannot expect a perfect solution here. > 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. [snip] > 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). PL:> I like that a lot. So I suppose this is what we'd have: EncryptionUpdateRequest ::=SEQUENCE { keyProtectionMethod KeyProtectionMethod OPTIONAL, ..., synchFlag INTEGER(0..255) OPTIONAL -- New PT component } MEU:> I'm missing the master/slave direction choice here.... I would prefer that we _require_ the master to use the PT provided by the slave and that this value therefore not be a _proposed_ PT. I simply see no reason to allow this kind of flexibility in the master. MEU:> I fully agree, I should have said "indicated" instead of proposed. Then there is the issue of the master asynchronously updating the key for a slave-to-master logical channel. To be consistent, I would prefer that we have the master request the PT from the slave. We could hi-jack the encryptionUpdateRequest command for this because it otherwise isn't conveyed from master to slave. The master in effect requests that the slave request a new key from it. We would move from the current dialog: slave master <- encryptionUpdate(1, 97, AES(sharedSecretKey, sessionKey2)) <- - - RTP(96, AES(sessionKey1, payload)) - - - <- - - RTP(97, AES(sessionKey2, payload)) - - - to this one (I also included the proposed Ack, discussed above): slave master <- encryptionUpdateRequest(1) encryptionUpdateRequest(1, sharedSecret, 97) -> <- encryptionUpdate(1, 97, AES(sharedSecretKey, sessionKey2)) <- - - RTP(96, AES(sessionKey1, payload)) - - - encryptionUpdateAck(97) -> <- - - RTP(97, AES(sessionKey2, payload)) - - - MEU:> Paul, I'm not certain, if I fully understand what you're saying here, or for what that is exactly good for. Let me ask: is it to avoid that there might be some sort of race condition such that two key update events overlap: one key update issued by the master to the slave for a slave-to-master logical channel while at the same time the slave requests a new key from for that particular channel from the master? This appears as a tricky situation... More signaling and another (inconsequential) round-trip delay, but it would be bullet-proof. No conflicts, no synch problems. In the mean time, we should at least identify the possibility of a conflict in the current standard and suggest how to deal with it. MEU:> ok we should do that. Any suggestions, proposals? In any way: I see that we are converging in the same direction and soon agree on a common solution :) So this calls action for me as editor. 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). If you want I would be pleased to make this a joint contribution between IPdialoge (?) and Siemens. What do you think? Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

3 2

more questions about h.341
by wu.yongming＠ZTE.COM.CN 27 Aug '02

27 Aug '02

hi,experts i got such a question(i am not sure if it really is a question). according to h.341,a MCU which has both MC and MP should provide with both of MIB modules. in a case that MC and MP are implemented in different box,how can these two MIB modules be deposited?one way is that MP'MIB is realized in MC,MP will report all information to MC periodically. and NMS only deals with MC,i doesn't realize MC and MP are separated.but i feel this way has some shortcomings.i think it is ideal MC and MP can be managed as separated devices.this way is more graceful.but h.341 seems only to consider MCU as a whole. in summary,i hope the following solution is possible: NMS <------->MC Agent+MC[mc mib] --- ^ | | > wholely as a MCU | | |----------->MP Agent+MP[mp mib] --- hope to hear your comments. thanks in advance! wuym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Report of the Raleigh meeting
by OKUBO Sakae 24 Aug '02

24 Aug '02

Dear SG16 experts, The subject document is available at the following place: http://standard.pictel.com/ftp/avc-site/0208_Ral/TD-03.zip Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Flaws in H.235 media encryption
by Paul Long 21 Aug '02

21 Aug '02

comments inline (and boy are they long this time) > 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. [snip] > > -----Original Message----- > From: Paul Long [mailto:plong@packetizer.com] > Sent: Monday, August 12, 2002 7:39 PM > To: itu-sg16(a)echo.jf.intel.com > Cc: Euchner Martin ICN M SR 3 > Subject: Flaws in H.235 media encryption > [snip] > 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). PL:> But the Voice Encryption Security Profile requires re-key: D.7.2/H.235v2: "The key refresh rate shall be such that no more than 2 [^]32 blocks are encrypted using the same key." Besides this requirement, I just thought that re-keying was good practice in general, but I'm new to the field of security. What is best practice for this and what are the considerations? Hmmm... doing some quick calculations, it looks like it could take at least a few years to reach 2^32 blocks. Is your point that, since most calls don't last months or years, it's probably okay not to ever re-key? [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). 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. Otherwise, we should add an encryptionUpdateAck component to the type CHOICE of the MiscellaneousCommand type. It would look like this: encryptionUpdateAck SEQUENCE { synchFlag INTEGER(0..255), ... }, > 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? PL:> Remember that TCP is a streaming protocol, so I doubt whether there is any way to know whether a particular sequence of bytes, e.g., a TPKT, has been received at the far end. Even if there were, I doubt whether all TCP implementations would provide this mechanism. Therefore, we cannot rely on the transport layer to ack receipt of the new key. Nice try, though. :-) > 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. PL:> That would sort of work. It also has the benefit of not having to change the RTP payload type for the new logical channel. There are disadvantages, however: 1. H.235 requires the use of encryptionUpdate (11.1/H.235v2: "After receiving an encryptionUpdateRequest, a master shall send out encryptionUpdate."). 2. replacementFor requires a LOT more signaling, i.e., OLC/OLCAck/CLC/CLCAck. 3. Possible (effective) packet loss if the first packet of the new channel arrives before the last packet of the old channel, thereby possibly causing noticeable media artifact or delay. 4. Requires twice the resources temporarilly while the two logical channels overlap, e.g., two sockets. 5. Overall increased complexity. We would basically be trading the lack of synchronicity between the control channel and the media logical channel for the lack of synchronicity between two media logical channels. I vote, no. > 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). PL:> You are correct--H.233 does not re-key, but it does have an analogous mechanism to update the initialization vector. H.324 added the codepoint, h233IVResponseTime, to H.245 to express how long the transmitter should wait between transmitting a new IV and transmitting frames based on that IV. This is what I was referring to. > 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). PL:> Yeah, we gotta fix this. Unfortunately, encryptionUpdate does not have a type of its own that we can extend. We would have to extend the EncryptionSync type, but this is used in other contexts where the extensions would have no meaning. The alternative is to add a new codepoint that obsoletes encryptionUpdate. We would define a new direction type, e.g., EncryptionUpdateDirection ::=CHOICE { masterToSlave NULL, slaveToMaster NULL, ... } and add this to the type CHOICE of the MiscellaneousCommand type: encryptionUpdateCommand SEQUENCE { encryptionSync EncryptionSync, direction EncryptionUpdateDirection, ... } The request type would be extended thusly: EncryptionUpdateRequest ::=SEQUENCE { keyProtectionMethod KeyProtectionMethod OPTIONAL, ..., direction EncryptionUpdateDirection OPTIONAL, } > 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. PL:> The problem is not that LCNs are not know--they are all indeed know by both sides--but that they are ambiguous. [snip] > 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. PL:> No, there are four re-key scenarios, and replacementFor would only address the one where the master asynchronously updates the key for a master-to-slave logical channel. Plus, there are the general problems that I pointed out, above, with the replacementFor solution. > 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. [snip] > 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). PL:> I like that a lot. So I suppose this is what we'd have: EncryptionUpdateRequest ::=SEQUENCE { keyProtectionMethod KeyProtectionMethod OPTIONAL, ..., synchFlag INTEGER(0..255) OPTIONAL -- New PT component } I would prefer that we _require_ the master to use the PT provided by the slave and that this value therefore not be a _proposed_ PT. I simply see no reason to allow this kind of flexibility in the master. Then there is the issue of the master asynchronously updating the key for a slave-to-master logical channel. To be consistent, I would prefer that we have the master request the PT from the slave. We could hi-jack the encryptionUpdateRequest command for this because it otherwise isn't conveyed from master to slave. The master in effect requests that the slave request a new key from it. We would move from the current dialog: slave master <- encryptionUpdate(1, 97, AES(sharedSecretKey, sessionKey2)) <- - - RTP(96, AES(sessionKey1, payload)) - - - <- - - RTP(97, AES(sessionKey2, payload)) - - - to this one (I also included the proposed Ack, discussed above): slave master <- encryptionUpdateRequest(1) encryptionUpdateRequest(1, sharedSecret, 97) -> <- encryptionUpdate(1, 97, AES(sharedSecretKey, sessionKey2)) <- - - RTP(96, AES(sessionKey1, payload)) - - - encryptionUpdateAck(97) -> <- - - RTP(97, AES(sessionKey2, payload)) - - - More signaling and another (inconsequential) round-trip delay, but it would be bullet-proof. No conflicts, no synch problems. In the mean time, we should at least identify the possibility of a conflict in the current standard and suggest how to deal with it. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Flaws in H.235 media encryption
by Euchner Martin ICN M SR 3 21 Aug '02

21 Aug '02

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(a)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

1 0

Tests!![via LSMTP - see www.lsoft.com]
by Roy, Radhika R, ALASO 20 Aug '02

20 Aug '02

Pl. ignore this message

1 0

ITU-SG16 Working Again[via LSMTP - see www.lsoft.com]
by Meyer, Greg W 19 Aug '02

19 Aug '02

Dear ITU-SG16 Experts: I apologize for the recent problems with the ITU-SG16 mail server (listserv). It appears that a vital configuration file had been deleted by a misbehaved program (virus). The file has been restored (as of 11am PDT today) and the list is again operational. In addition, please note that the listserv software has been upgraded. You may receive responses from listserv when you send mail to the list to confirm by clicking on a URL link. But the links won't work externally from Intel so you will need to continue to confirm by replying to listserv with "OK" in the body of the message (without the quotes). Here's the step-by-step: 1. To send mail to the Study Group 16 experts, send mail to itu-sg16(a)lists.intel.com. 2. Listserv will respond asking you to confirm the message. Don't click on the URL link in the message. Instead, reply to the message with "OK" as the first line in the body of the message (without the quote marks). 3. Listserv will then send the message to the ITU-SG16 mail list. If you experience any problems with the list, please let me know. Thank you, Greg Meyer Intel Research & Development greg.w.meyer(a)intel.com

1 0

Saturday morning - Do I get this message?[via LSMTP - see www.lsoft.com]
by Sessions, Barbara 17 Aug '02

17 Aug '02

This is the listserv admin testing again. Please ignore and sorry for the inconvenience. Barbara.Sessions(a)intel.com. This is to see if lsmtp is working.

1 0

FW: This is a test with address changed[via LSMTP - see www.lsoft.com]
by Sessions, Barbara 16 Aug '02

16 Aug '02

-----Original Message----- From: Sessions, Barbara Sent: Friday, August 16, 2002 7:04 PM To: 'ITU-SG16(a)echo.intel.com' Subject: This is a test with address changed ITU-SG16@echo. <mailto:ITU-SG16@echo.intel.com> jf.intel.com Will this work?

1 0