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@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@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@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@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@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@hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul@TRILLIUM.COM; ITU-SG16@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@TRILLIUM.COM on 05/31/2001 06:35:31 PM

Please respond to "Paul, Manoj" mpaul@TRILLIUM.COM

To: ITU-SG16@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@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com