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@siemens.atea.be -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Monday, July 24, 2000 10:14 To: ITU-SG16@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@nokia.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