Contribution APC-1995.zip uploaded
jsegers at LUCENT.COM
Tue Oct 31 05:10:51 EST 2000
Thanks for your answers. Please see my comments marked with meu:> below.
| Dipl.-Inf. Phone: +49 89 722 55790
| Martin Euchner Fax : +49 89 722 46841
| Siemens AG
| ICN M NT 5 mailto:Martin.Euchner at icn.siemens.de <mailto:Martin.Euchner at icn.siemens.de>
| mailto:martin.euchner at ties.itu.int <mailto:martin.euchner at ties.itu.int>
| Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm
| D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de>
Von: jaakko.sundquist at nokia.com [SMTP:jaakko.sundquist at nokia.com]
Gesendet am: Dienstag, 31. Oktober 2000 09:12
An: Martin.Euchner at icn.siemens.de; ITU-SG16 at mailbag.cps.intel.com
Betreff: RE: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
See my comments embedded.
> Hi Jaakko,
> I'm not certain, whether I really understand the purpose of
> the EncryptionToken.
> If I look at Annex G v1, H.235 Clear and CryptoTokens are
> always present in each Annex G message; they are conveyed
> within AnnexGCommonInfo and thus are already part of each
> annex G message. Thus, I would say, that EncryptionToken is
> somewhat redundant and we do not need that this way.
You're quite right, the encryptionToken certainly seems unnecessary, thus
I'll take it away from the contribution.
Meu> ok. Thanks.
> The other question I have concerns AuthenticationRejection:
> Why do you reverse tunnel - that is, feed back - the tunneled
> message in the reject?
Well, this was just a thought that maybe it would be beneficial, if the
originating gatekeeper would receive the (presumably) same message it has
tunneled, so that it can make sure that the message indeed is the one it has
sent. On the other hand, since we are talking about communications taking
place through a route of trusted parties (also secured with H.235 methods),
maybe this kind of integrity check is unnecessary. What do you think?
Meu:> If the reverse tunnel is solely for security purposes, then I do not consider this useful. As you said, the entire authentication message including the tunneled message is integrity protected on a hop-by-hop basis. Due to the principle of chained trust in the security architecture, the MT can be certain that the authentication message has not been tampered in transit. As a conclusion, the reverse tunnel does not make sense from a security point of view.
I thought, that the reverse tunnel were useful perhaps for matching the confirmation with the request message. But then, some simpler means than conveying the entire message should be sufficient.
What about the following scenario:
Several MTs "attach" to the same GK. All these MTs are subscribed to the same AuF. Thus, the GK has several outstanding AuthenticationRequests issued for each MT. How does the GK associate the related AuthenticationConfirmation then?
What do you think?
> Finally a general question:
> Once there was a discussion that Annex G not only be used
> among Border elements as currently defined in the H.225 Annex
> Gv1 scope, but to extend its usage for mobility purposes. If
> this were true, then Annex G could be applied also between
> the GK-VLF/BE and between HLF/BE-AuF. What is the current
> status of that discussion?
I guess this issue hasn't been throughly discussed yet. My personal opinion
is that we should extend the usability of the H.225 Annex G protocol also to
other functional entities besides the BE. On the other hand, I would be
quite happy also, if we would limit the first version of H.323 Annex H by
not handling all the interfaces in the architecture diagram and concentrate
on the VLF - HLF -interface (with or without BEs) instead. The reason for
the latter argument is that I would assume that implementors might be quite
happy with co-located functional entities so that they would have a
GK/VLF/BE and HLF/AuF/BE elements, thus necessitating only the mentioned
VLF/BE - HLF/BE network interface.
Meu>: this could simplify things a lot!
Thanks for the mail, it was very useful.
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