Re: H.235 Security Blues

27 Jul 2001


      Hi Manoj,
the scenario that you described refers to a mixed environment that should cope both with security (entities, protocols) and also with unsecured ones. It is true, that such mixed environments do not provide the same security level as a secure environment without any unsecured entities.
The problem with mixed environments is, that a secure entity should also process insecure messages from untrusted entities but has no way to know where such unprotected messages really came from. This issue not new and security experts have always warned people to realize this. Let me note, that exactly this kind of discussion comes up, when people add security later on and seek some way how secure and insecure (= older) systems could interwork in a secure way. Thus, it is exactly this weakness of insecure systems that breaks the entire security. I understand that this situation is unsatisfactory, but we have to live with that as long as dual mode or mixed environments are the case.
However, your idea using pre-configured security in the entities (in a mixed environment) would be equal to the situation where all entities have implemented security but no insecure one is permitted to participate (which would then be a non-mixed security environment). Thus, as you see, this is either a contradiction or impossible to fulfill and wouldn't help anyway.
As a conclusion, no one should expect to obtain any better security in a mixed environment than in an unsecured environment. If you really want to improve, the only way to achieve this, is to abandon the insecure entities and replace them by secure ones or forbid the secured entities from accepting any insecure message. This however is matter of security policy in your operating environment. It is a local matter how you would or could enforce such a security policy in your systems. Using H.235 you have all the means to determine whether a message has been secured (through the OIDs) and also verify (by checking the cryptographic hash value) whether it origins from a trusted entity. This should be sufficient to decide whether or not to discard a message.
Think about!
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:   Wednesday, July 25, 2001 7:25 PM
To:     'Euchner Martin'; Paul, Manoj; ITU-SG16@mailbag.cps.INTEL.COM
Subject:        RE: H.235 Security Blues
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@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@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@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