H.235 Security Blues

Euchner Martin Martin.Euchner at ICN.SIEMENS.DE
Thu Jul 26 11:06:31 EDT 2001


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 at icn.siemens.de
|                                mailto:martin.euchner at 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 at trillium.com]
Sent:   Wednesday, July 25, 2001 7:36 PM
To:     'Euchner Martin'; Paul, Manoj; ITU-SG16 at 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 at icn.siemens.de]
Sent: Wednesday, July 25, 2001 7:50 AM
To: 'Paul, Manoj'; Euchner Martin; ITU-SG16 at 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 at icn.siemens.de
|                                mailto:martin.euchner at 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 at trillium.com]
Sent:   Tuesday, July 24, 2001 8:53 PM
To:     'Euchner Martin'; ITU-SG16 at 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 at ICN.SIEMENS.DE]
Sent: Tuesday, July 24, 2001 9:39 AM
To: ITU-SG16 at 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 at icn.siemens.de
|                                mailto:martin.euchner at 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 at icn.siemens.de
|                                mailto:martin.euchner at 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 at TRILLIUM.COM]
Sent:   Thursday, July 19, 2001 9:15 PM
To:     ITU-SG16 at 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 at hss.hns.com [mailto:ssilvy at hss.hns.com]
Sent: Thursday, May 31, 2001 9:26 PM
To: mpaul at TRILLIUM.COM; ITU-SG16 at 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 at HSSBLR, Ivan T Varghis/HSSBLR at HSSBLR
cc:

Subject:


---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001
09:46 AM ---------------------------


"Paul, Manoj" <mpaul at TRILLIUM.COM> on 05/31/2001 06:35:31 PM

Please respond to "Paul, Manoj" <mpaul at TRILLIUM.COM>

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

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

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

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



More information about the sg16-avd mailing list