- sg16-avd - lists.packetizer.com

You Can Too #539D
by Frank Jerwin 26 Jul '01

26 Jul '01

***** This is an HTML Message ! *****

1 0

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

26 Jul '01

Hi Manoj, there is always the risk of denial-of-service attacks where any response message with some security hints were maliciously deleted, would leave the EP in uncertainty. I do not see a way how such attacks could be effectively be prevented at an application level. Implementation should be prepared of such losses. However, when we put the denial-of-service issues to the side, there is at least some way, how the EP obtains some security status information from the GK. This is as you described when the GK would send a FACILITY with reason code indicating a security failure. This appears as a reasonable solution. I do not see particular benefit, to make any exceptional distinction with the processing of manipulated RELEASE COMPLETE against any other manipulated H.225.0 message, where you proposed not to send back a FACILITY? I would safely propose that the GK drops such a RELEASE COMPLETE and responds with a FACILITY + securitydenial as in any other case. Finally, I can see some value in that the EP can align a FACILTY with security reason to the failed call signaling message. I'm not so certain whether there is really a need to distinguish the individual messages with the FACILITY message. This would have to be signaled explicitly somewhere in the message. At present, my impression is that H.225.0 does not provide such an explicit signaling capability. On the other hand, there is probably no need for adding fields to H.225.0. Assuming TCP transport, the EP should be able to relate such a FACILITY + securitydenial with the pending call signaling message and its state. Any other FACILITY message received with security denial which is unrelated to any unsent call signaling message should be treated by the EP as an attack. This could be implemented without changes to the standard. The only item I hear, is to make the procedure for the GK obvious, to respond with a FACILITY + security denial in case of security failures. This should be described more precisely in the Implementors Guide, I 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: Wednesday, July 25, 2001 7:36 PM To: 'Euchner Martin'; Paul, Manoj; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues 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: FastStart in Call Proceeding
by Francois Audet 25 Jul '01

25 Jul '01

In the FACILITY message. It is described somewhere in H.225.0 and H.323. Look in version 4 (It might also be in v3, but I don't remember). -----Original Message----- From: Shan Lu [mailto:slu@NEXTONE.COM] Sent: Wednesday, July 25, 2001 10:47 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: FastStart in Call Proceeding Hi all, I have a question when the FastStart element is returned in the Call Proceeding message by the called EP. The problem arises when a GK is routing the signalling and let's further assume that the GK has already sent a Call Proceeding to the calling EP before the Call Proceeding from the called EP arrives. How is the GK supposed to do to relay the FastStart element to the calling EP asap? Another call proceeding? Facility? You have the same issue even without FastStart. Say the call proceeding may contain the called EP's H245 address which the GK should send to the calling EP right away. Appreciate any responses. Regards, Shan Lu NexTone Communications ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FastStart in Call Proceeding
by Shan Lu 25 Jul '01

25 Jul '01

1 0

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