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