September 2002 - sg16-avd - lists.packetizer.com

H.460.QoSMon
by Tom-PT Taylor 19 Sep '02

19 Sep '02

Where is the last (first?) available draft of this document? I haven't been able to track it down. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Correction Of (was) H.248 Annex M.4: Packages for H.323/H.324 int erworking
by Tom-PT Taylor 19 Sep '02

19 Sep '02

H.248 Annex M.4 has an erroneous view of the role of the MUX descriptor, which I failed to catch before the document was approved. The question is: how far have people taken their implementations? Would it be possible to redo this part of the document correctly? Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

RE: PictureTel Site Blocked
by simao.campos＠itu.int 19 Sep '02

19 Sep '02

Dear colleagues, it seems that these problems with the PictureTel site keep recurring. I would like to suggest an alternative, that could be discussed in Geneva in October. TSAG has created a mechanism for creating "semi"-open FTP areas under TIES (for the purp[ose of communicating with organizations outside the ITU), outside of the traditional informal FTP area of the SGs. This area has a username/password, but these can be communicated to the interested parties. In this sense, I would like to investigate with you what would be your feeling about migrating all the material that is now available in the PicTel FTP site into such an area hosted by the ITU, created for SG 16. If your response is positive, I would start checking internally how can we most expeditely move into that direction. Best regards, Simao -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: 18 September 2002 22:08 To: ITU-SG16(a)echo.jf.INTEL.COM Subject: PictureTel Site Blocked The PictureTel site is giving me an error message: maximum number of anonymous users exceeded. I expect this is the FTP problem they had before. The administrator address provided in the error message (Patrick Luthi's old address) bounces, so I don't know who to contact to reset the server. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

PictureTel Site Blocked
by Tom-PT Taylor 18 Sep '02

18 Sep '02

The PictureTel site is giving me an error message: maximum number of anonymous users exceeded. I expect this is the FTP problem they had before. The administrator address provided in the error message (Patrick Luthi's old address) bounces, so I don't know who to contact to reset the server. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 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