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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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, …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
