[H.323 Mobility:] Update to Service Definitions for Annex H - > a question

Roelands Marc Marc.Roelands at SIEMENS.ATEA.BE
Mon Jul 31 04:53:17 EDT 2000


Hi Jaakko, Hi all,

Here is an attempt to answer your question(s).
As you say, the text is about requirements and so does not specify how 5.1.2
bullet 1 can be implemented. However, the text says "verification of the
authenticity of the Terminal" and this is literally what is intended. So no
association identifier of some sort, as you mention as a second
interpretation, is directly meant. (However this might turn out to be an
element for realization of this bullet.)
Important however, is the fact that the authentication of a terminal is not
useful for the Domain (taken out the indicated special purposes) _unless_ it
can be associated with particular Users. Thus, an authenticated Terminal can
do certain (restricted) things on behalf of Users that have registered with
it. What is further assumed by the text is that some element in the Domain
(likely a GK) knows which Users are registered at that (authenticated)
Terminal. As mentioned in footnote 7, a way to transfer this association
knowledge (possibly indexed by some identifier) between these Domain
elements is needed in order to enable the Terminal to act on behalf of the
User also when roaming.

Hope this clarifies.

(Thinking again about the temporary identifier issue you bring up, things
can become more complex when one considers that for privacy reasons one may
not want to have a straightforward way of finding out which Users are
"linked" by means of their registration at the same Terminal, but I'm sure
that we don't want to cope with such issues already in this first phase
Annex H.)

Regards,
Marc Roelands
Siemens ICN
Dept. NC SD
Atealaan 34
B-2200 Herentals
Belgium
Tel.: +32 14253965
Fax:  +32 14222994
E-mail: marc.roelands at siemens.atea.be


-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
Sent: Monday, July 24, 2000 10:14
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: [H.323 Mobility:] Update to Service Definitions for Annex H
- > a question


Hi Marc et al,

I just finished reading MD-102a and I have a couple of questions. First of
all, though, I want to thank you guys for the excelent contribution, I
really liked it.

Actually I have just one thing that I don't quite understand. In section
5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say
that it enables the verification of the authenticity of the terminal is
context of the association it has with the Mobile User. You also explain
this a bit further by adding that this is used to verify that the terminal
can act on behalf of the authenticated User using it but you still state
that the identity of the terminal is only relevant for the purposes of
denying the usage of stolen terminals, etc. (black lists). So my question is
that are you talking here about authenticating the terminal or are you
referring to authenticating some sort of identifier that is used for the
association between the terminal and the user? Your statement in item 3.
about not needing to authenticate the user in subsequent terminal
re-registrations would also seem to indicate the latter. Thus are you
thinking of implementing a way to avoid the User authentication at least in
Intra-zone location changes by introducing some sort of temporary local
identifier for the terminal/user pair? I know that these are just
requirements, but these statements seem to lead to that direction, if I have
understood them correctly.
The idea seems to be worth while to consider and we should discuss this
further, but I don't quite see, how the terminal/user pair could really be
authenticated, i.e. you can authenticate the User (by contacting the AuF)
and you can authenticate the terminal (if proper cryptographic methods are
specified also for the terminal), but how can you authenticate their
association?

Or am I just reading too much into this?

Otherwise the contribution seems fine and I would suggest the addition of
its contents to the draft Annex H. Let's have a bit of discussion before
that, however.

------------------------------------------------
Jaakko Sundquist           *
+358 50 3598281            * Audere est Facere!
jaakko.sundquist at nokia.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