July 2001 - sg16-avd - lists.packetizer.com

Re: H.235 Security Blues
by Paul, Manoj 25 Jul '01

25 Jul '01

Hi Martin, The only problem I see with that approach is that the endpoint shall have no way to find the reasons for not getting a response from GK. If someway could be found to make EP know that it;s last message could not pass the security tests, it may be able to take a recovery action. (As it happens with RAS messages). Do you think GK can send FACILITY with reason SecurityDenied to the endpoint when it gets a call signalling message which fails security test. GK can silently drop that message but sends FACILITY to the endpoint, except when the incoming 225 message failing the security test is RELEASE COMPLETE. Although, the endpoint shall become aware of the reason for GK dropping it's messages, it shall still have no way to distinguish which call signalling message failed the security test. What do you suggest? best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 7:50 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Manoj, The issue with security denial is correct as you stated it. For RAS, sending a reject message with security denial as reason code should work. What is not clearly specified in H.235 at the moment is, what to do with security failures during call signaling. If one would reply with ReleaseComplete and similar security reason code indicated, an attacker could very easily launch a denial-of-service attack and make the peer call signaling entity drop the call. That is probably not what we want with security. Thus, I'm really hesitating to add a sentence to H.235 saying that whenever a secured call signaling message such as Connect with invalid security has been received, ReleaseComplete with security denial should/shall be sent. I pretty much prefer a much simpler yet more secure variant: Instead of replying with a message in case of failure, it should be sufficient for the recipient to discard the illegal message and for the sender to obtain a timeout and then try again. I think, that I should add a similar statement to D.6.3.1. Do you agree? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 8:53 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Experts, As I work through H.235, questions are popping to me. May be I should pack them in one e-mail and send it on reflector next time. My question is more to do with the procedure when Auth/Int on a H225 message fails. Clause D.6.3.1 of H.235 V2 states that GK should send a correponding Reject message with SecurityDenial reason. That may work fine for RAS, but for H.225 messages, the only way would be to send Release Complete to the peer with reason as SecurityDenied. Is that so? If yes, then doesn't it allows a hostile router to force GK/endpoint to release the established calls by sending it spurious messages? best regards Manoj Paul. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Paul, Manoj 25 Jul '01

25 Jul '01

Hi Martin, Thanks for your reply. I have a small concern to the fact that GK should let the EP know of GK initiated message security aspects in security tokens. I think an endpoint should a-priori know if it expects messages (RAS and 225) from GK to contain security tokens and hash values. If endpoint determines this at run time using in-band mechanisms, it may potential fall pray to a hostile router which sends it an unsecured message pretending as a GK. An EP, in such a case, would have no way to determine if GK indeed wants it to send unsecured messages. I shall appreciate your comments. best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 1:31 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the GK determines whether to apply mutual authentication; i.e. authenticate and integrity protect the RAS messages towards the EP. This is a matter of security policy and therefore something, that is a local matter. For security reasons, I would recommend applying mutual authentication instead on just single sided authentication. There is no need to negotiate this feature, as an endpoint can always recognize whether messages from the GK are secured or not. The EP does this by looking at the presence of the various OIDs in the security tokens. Missing OIDs = no security. Thus, this feature is always indicated in-band in each message. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 7:55 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Euchner Martin 25 Jul '01

25 Jul '01

Manoj, The issue with security denial is correct as you stated it. For RAS, sending a reject message with security denial as reason code should work. What is not clearly specified in H.235 at the moment is, what to do with security failures during call signaling. If one would reply with ReleaseComplete and similar security reason code indicated, an attacker could very easily launch a denial-of-service attack and make the peer call signaling entity drop the call. That is probably not what we want with security. Thus, I'm really hesitating to add a sentence to H.235 saying that whenever a secured call signaling message such as Connect with invalid security has been received, ReleaseComplete with security denial should/shall be sent. I pretty much prefer a much simpler yet more secure variant: Instead of replying with a message in case of failure, it should be sufficient for the recipient to discard the illegal message and for the sender to obtain a timeout and then try again. I think, that I should add a similar statement to D.6.3.1. Do you agree? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 8:53 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Experts, As I work through H.235, questions are popping to me. May be I should pack them in one e-mail and send it on reflector next time. My question is more to do with the procedure when Auth/Int on a H225 message fails. Clause D.6.3.1 of H.235 V2 states that GK should send a correponding Reject message with SecurityDenial reason. That may work fine for RAS, but for H.225 messages, the only way would be to send Release Complete to the peer with reason as SecurityDenied. Is that so? If yes, then doesn't it allows a hostile router to force GK/endpoint to release the established calls by sending it spurious messages? best regards Manoj Paul. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Euchner Martin 25 Jul '01

25 Jul '01

Hi Manoj, the GK determines whether to apply mutual authentication; i.e. authenticate and integrity protect the RAS messages towards the EP. This is a matter of security policy and therefore something, that is a local matter. For security reasons, I would recommend applying mutual authentication instead on just single sided authentication. There is no need to negotiate this feature, as an endpoint can always recognize whether messages from the GK are secured or not. The EP does this by looking at the presence of the various OIDs in the security tokens. Missing OIDs = no security. Thus, this feature is always indicated in-band in each message. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 7:55 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Paul, Manoj 24 Jul '01

24 Jul '01

Experts, As I work through H.235, questions are popping to me. May be I should pack them in one e-mail and send it on reflector next time. My question is more to do with the procedure when Auth/Int on a H225 message fails. Clause D.6.3.1 of H.235 V2 states that GK should send a correponding Reject message with SecurityDenial reason. That may work fine for RAS, but for H.225 messages, the only way would be to send Release Complete to the peer with reason as SecurityDenied. Is that so? If yes, then doesn't it allows a hostile router to force GK/endpoint to release the established calls by sending it spurious messages? best regards Manoj Paul. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Paul, Manoj 24 Jul '01

24 Jul '01

Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Euchner Martin 24 Jul '01

24 Jul '01

Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | 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/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Stressed With Debt?
by Kirk Mitchell 21 Jul '01

21 Jul '01

Consolidate all your debt into ONE, EASY monthly payment! We will help you: *Eliminate interest charges *Waive late fee charges *Improve your credit rating And best of all, lower your monthly payments by 40%-60% and KEEP MORE CASH IN YOUR POCKET! Take just 1 minute to complete our Credit Card Consolidation Form and one of our experienced professional consultants will contact you! http://00000101.00000247.00000040.00000054 There is no obligation and our service is fast and free! All information is kept strictly confidential. **************************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply: mailto:rmtoday21@yahoo.ca?subject=remove **************************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 (8.1) Phase A - Call Setup
by Peter Price 20 Jul '01

20 Jul '01

Hi folks, I think I may have found some incorrect text in H.323 8.1 The same text appears in both V3 and V4 so I suspect nobody has commented before. In the paragraph beginning: "An endpoint shall be capable of sending the Alerting message. ..." it goes on to say: "If an endpoint can respond to a Setup message with a Connect, Call Proceeding, or Release Complete within 4 seconds, it is not required to send the Alerting message. An endpoint sending the Setup message can expect to receive either an Alerting, Connect, Call Proceeding, or Release Complete message within 4 seconds after successful transmission." I believe the first sentence here should really be discussing the requirement to send a Call Proceeding (not Alerting) message. The period of 4 seconds in the last sentence is related to T303 which is specifically terminated by a Call Proceeding message in order to extend the timeout for the sending endpoint. I think the sentence should read: "If an endpoint can respond to a Setup message with a Connect, Alerting, or Release Complete within 4 seconds, it is not required to send the Call Proceeding message." This is then consistent with the use of Call Proceeding described in 8.1.8.2 (second para). Peter Price ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 4

AW: H.323 (8.1) Phase A - Call Setup
by Guntram Diehl 20 Jul '01

20 Jul '01

Hi all, I would recommend to read Q.931. This gives a lot of background information about the use of the different messages. Guntram > -----Ursprüngliche Nachricht----- > Von: Peter Price [mailto:PeterP@VEGASTREAM.COM] > Gesendet: Freitag, 20. Juli 2001 15:37 > An: ITU-SG16(a)MAILBAG.INTEL.COM > Betreff: Re: H.323 (8.1) Phase A - Call Setup > > > Paul, > > in fact, on further reflection, your second paragaraph > highlights the error > in (8.1) > We both agree Alerting should be sent to the caller as soon > as the callee's > phone is ringing but the text opens the door for someone to send Call > Proceeding and then not ever send Alerting. > > It becomes clearer to me that the original intent was almost certainly > "If an endpoint can respond to a Setup message with a Connect within 4 > seconds, it is not required to send the Alerting message." > Reference to Call Proceeding is incorrect and to Release Complete > irrelevent. > > I'm not sure what should be done to clarify the purpose of > Call Proceeding. > I think it being optional for terminal devices has led people > to ignore its > correct use in gateways which are an important part of the > network. Perhaps > this need a separate thread. > > Peter > > > -----Original Message----- > > From: Peter Price [mailto:PeterP@VEGASTREAM.COM] > > Sent: 20 July 2001 14:05 > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Re: H.323 (8.1) Phase A - Call Setup > > > > > > Paul, > > > > I forgot to say that I agree with your second paragraph with > > the proviso > > that it might take more than 4 seconds to send the Alerting. > > Call Proceeding is not a substitue for Alerting its just an > > indication that > > the caller should not give up too quickly. > > > > Pete > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > Sent: 20 July 2001 12:48 > > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > > Subject: Re: H.323 (8.1) Phase A - Call Setup > > > > > > > > > Peter, > > > > > > Alerting was the intent. Call Proceeding not produce a > > > ringing sound in the > > > caller's ear. H.323 devices have to be able to send an > > > Alerting, though > > > they're not required to do so if they can send a Connect > > > within 4 second. > > > The 4 seconds is the T303 timeout and the T303 timer is > > disabled when > > > receiving Alerting, too... not just Call Proceeding. > > > > > > The ideas are related, but independent. What we have seen > > > some folks do is > > > send a Call Proceeding to the caller and then nothing > else until the > > > connect. The result is that the calling party hears silence > > > for a very long > > > time: that's not good. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Peter Price" <PeterP(a)VEGASTREAM.COM> > > > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > > > Sent: Friday, July 20, 2001 6:54 AM > > > Subject: H.323 (8.1) Phase A - Call Setup > > > > > > > > > > Hi folks, > > > > > > > > I think I may have found some incorrect text in H.323 8.1 > > > > > > > > The same text appears in both V3 and V4 so I suspect nobody > > > has commented > > > > before. > > > > > > > > In the paragraph beginning: > > > > "An endpoint shall be capable of sending the Alerting > > message. ..." > > > > > > > > it goes on to say: > > > > "If an endpoint can respond to a Setup message with a > > Connect, Call > > > > Proceeding, or Release Complete within 4 seconds, it is not > > > required to > > > send > > > > the Alerting message. An endpoint sending the Setup message > > > can expect to > > > > receive either an Alerting, Connect, Call Proceeding, or > > > Release Complete > > > > message within 4 seconds after successful transmission." > > > > > > > > I believe the first sentence here should really be > discussing the > > > > requirement to send a Call Proceeding (not Alerting) message. > > > > The period of 4 seconds in the last sentence is related to > > > T303 which is > > > > specifically terminated by a Call Proceeding message in > > > order to extend > > > the > > > > timeout for the sending endpoint. > > > > > > > > I think the sentence should read: > > > > "If an endpoint can respond to a Setup message with a > > > Connect, Alerting, > > > or > > > > Release Complete within 4 seconds, it is not required to > > > send the Call > > > > Proceeding message." > > > > > > > > This is then consistent with the use of Call Proceeding > > described in > > > 8.1.8.2 > > > > (second para). > > > > > > > > Peter Price > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > > listserv(a)mailbag.intel.com > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0