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

Delayed Contribution from Waseda University
by OKUBO Sakae 29 Sep '02

29 Sep '02

Dear SG16 experts, I have submitted the following delayed contribution to ITU-TSB: Source: Waseda University Title: Study item for displaying remote PC presentations in H.300-series systems Outline: This submission is stimulated by the indication of Q.1/16 future work "H.320 Annex Multiple Streams" in the WP2/16 report of the February 2002 meeting (Section 3.5.13 of COM 16-R19). A current daily practice of face-to-face meetings, lectures, demonstrations, etc is to present PC files with an LCD projector. The interface between PC and projector is well established and stable these days. It will enhance the H.300-series videoconferencing systems if they incorporate the feature of remotely presenting the PC display image. It is available for your review at the avc-site: http://standard.pictel.com/ftp/avc-site/0210_Gen/Waseda_delayed_020928.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

2 2

ITU-T SG16 mailinglists
by OKUBO Sakae 29 Sep '02

29 Sep '02

Dear all, Recently the following ITU-T SG16 mailinglists subscribed to the Intel's itu-sg16(a)lists.intel.com mailinglist: > tsg16qd(a)itu.int > tsg16qf(a)itu.int > tsg16qg(a)itu.int > tsg16q2(a)itu.int > tsg16q3(a)itu.int > tsg16q4(a)itu.int > tsg16q5(a)itu.int A consequence is that if you post your message at itu-sg16(a)lists.intel.com and if you have not subscribed to those ITU-T mailinglists, you will receive a "non-member submission" warning. If you have a TIES account, then you can make subscriptions to those ITU-T mailinglists through the following page: http://www.itu.int/ITU-T/studygroups/com16/edh/subscribe.html Otherwise, you can ignore the warning. Your posting is still distributed by the Intel's itu-sg16(a)lists.intel.com to those who subscribed to it. -- 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

Decoding H.245 Messages
by Tom-PT Taylor 27 Sep '02

27 Sep '02

Naive question from someone who has never implemented ASN.1 PER: could I use the latest H.245 ASN.1 to decode H.245v5 and H.245v6 messages? 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

2 1

Meeting documents
by OKUBO Sakae 27 Sep '02

27 Sep '02

Dear SG16 experts, Somewhat belatedly, AVD-2252, integrated report of the Bruges meeting, is now available at the following place: http://standard.pictel.com/ftp/avc-site/0206_Bru/AVD-2252.zip Using this opportunity, let me remind you that you are requested to voluntarily post input documents (Delayed Contribution or Temporary Document) for the coming SG16 meeting at http://standard.pictel.com/ftp/avc-site/Incoming so that experts can review them in advance of the meeting. Please note, however, since the October meeting is an official ITU-T meeting, all the documents are managed by ITU-TSB. 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: comments on AVD 2253 from Raleigh
by Even, Roni 26 Sep '02

26 Sep '02

Paul, Single source is not a good definition, is it an a same IP address or is it the same encoder Roni > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, September 26, 2002 6:56 AM > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Martin Euchner > Subject: Re: comments on AVD 2253 from Raleigh > > > Roni, > > The current definition, which was drafted by Terry Anderson, > is pretty clear > that multiple payload streams must carry data from a single > "source", I > believe. Have a look at AVD 2257. > > Paul > > ----- Original Message ----- > From: "Even, Roni" <roni.even(a)polycom.co.il> > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; "Even, Roni" > <roni.even(a)polycom.co.il>; <ITU-SG16(a)echo.jf.INTEL.COM> > Cc: "Martin Euchner" <Martin.Euchner(a)icn.siemens.de> > Sent: Wednesday, September 18, 2002 4:06 AM > Subject: RE: comments on AVD 2253 from Raleigh > > > > Paul, > > > > I think that the requirement were to prevent audio and > video in the same > > stream on one side and to allow for multiple video or audio > in the same > > stream to be compatible with SIP capabilities and not only > for MOIP. So I > > think that there should be a text saying that in multiple > streams we do > not > > recommend audio and video in the same stream and to be able > to specify the > > packetization scheme for the multiple streams. > > Roni > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Tuesday, September 17, 2002 7:52 PM > > > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > > > Cc: Martin Euchner > > > Subject: Re: comments on AVD 2253 from Raleigh > > > > > > > > > Roni, > > > > > > , > > > > 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. > > > > > > We already have precedence for this, such as RFC 2833. In > > > addition, this > > > feature would only be used if both sides advertise the > > > capabilities, so I do > > > not expect to see anything break. > > > > > > > 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. > > > > > > This might be true. Would it be possible to add those > parameters as > > > necessary in the future? At the moment, the only use for > > > this capability at > > > the moment is for modem over IP, wherein every payload that > > > will be used is > > > understood based solely on the capability, I believe-- > > > perhaps I'm wrong. > > > In any case, the important thing is to know whether the > > > syntax precludes the > > > specification of additional parameters. > > > > > > > 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 > > > > > > Most definitely.. I would certainly welcome comments and > > > input in the area > > > of security. > > > > > > Paul > > > > > > > > >

2 1

Re: comments on AVD 2253 from Raleigh
by Even, Roni 25 Sep '02

25 Sep '02

Paul, I think that the requirement were to prevent audio and video in the same stream on one side and to allow for multiple video or audio in the same stream to be compatible with SIP capabilities and not only for MOIP. So I think that there should be a text saying that in multiple streams we do not recommend audio and video in the same stream and to be able to specify the packetization scheme for the multiple streams. Roni > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, September 17, 2002 7:52 PM > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Martin Euchner > Subject: Re: comments on AVD 2253 from Raleigh > > > Roni, > > , > > 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. > > We already have precedence for this, such as RFC 2833. In > addition, this > feature would only be used if both sides advertise the > capabilities, so I do > not expect to see anything break. > > > 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. > > This might be true. Would it be possible to add those parameters as > necessary in the future? At the moment, the only use for > this capability at > the moment is for modem over IP, wherein every payload that > will be used is > understood based solely on the capability, I believe-- > perhaps I'm wrong. > In any case, the important thing is to know whether the > syntax precludes the > specification of additional parameters. > > > 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 > > Most definitely.. I would certainly welcome comments and > input in the area > of security. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Meeting documents
by OKUBO Sakae 25 Sep '02

25 Sep '02

Dear SG16 experts, Somewhat belatedly, AVD-2252, integrated report of the Bruges meeting, is now available at the following place: http://standard.pictel.com/ftp/avc-site/0206_Bru/AVD-2252.zip Using this opportunity, let me remind you that you are requested to voluntarily post input documents (Delayed Contribution or Temporary Document) for the coming SG16 meeting at http://standard.pictel.com/ftp/avc-site/Incoming so that experts can review them in advance of the meeting. Please note, however, since the October meeting is an official ITU-T meeting, all the documents are managed by ITU-TSB. -- 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: [Security] Enhancements to H.233 and H.234
by Euchner Martin ICN M SR 3 20 Sep '02

20 Sep '02

Ok; sounds fine with me. 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: Wednesday, September 18, 2002 9:59 AM To: Euchner Martin ICN M SR 3; Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM Subject: RE: [Security] Enhancements to H.233 and H.234 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

2 1

AW: H.460.QoSMon
by Horvath Ernst 20 Sep '02

20 Sep '02

Tom, you can find the (first and only) draft in D211 of the February 2002 (Geneva) SG16 meeting . There will be an updated draft available for the forthcoming meeting. Regards, Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Gesendet am: Donnerstag, 19. September 2002 22:57 An: ITU-SG16(a)echo.jf.INTEL.COM Cc: 'Horvath Ernst' Betreff: H.460.QoSMon 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

RE: PictureTel Site Blocked
by Campos, Simao 20 Sep '02

20 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

3 2

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

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