I agree that H.235 provides already many useful security functions and signaling capabilities that could potentially be used also in annex G. Of course, it has to be described how they could be applied in the new scenario as H.235 does not know about administrative domains and communication among them. Please be aware, that the introduction of this new scenario clearly extends the H.323v2 scope and especially the scope of H.235. You can see this by looking at the high and low priority requirements in annex G. For example, there are requirements saying that border elements can mutually authenticate as well as a foreign GK can authenticate an entity in a different administrative domain. I do not quite see how both issues could be addressed by (present) H.235. The "remote authentication" issues sound challenging; to me; it is not quite clear what 'element' exactly is meant (is it a GK, an endpoint,...)? Another issue is authorization and access control. Present H.235 defines access (authorization) tokens that are useful between endpoints, GK and GW within a zone/administrative domain. Possibly, the mechanism could be extended for annex G purposes. Therefore, it appears to me that annex G requires at least certain "security glue" that describes for example how the authentication within a zone, between administrative domains and authorization fits together. I see also a requirement for non-repudiation services between border elements. H.235 presently does not define explicitly any non-repudiation services. What exactly is the purpose of this non-repudiation? Is it just limited to the border-to-border element communication using annex G protocols is it a more general requirement addressing also other H.323 communication carries across reference point A? Thus, all the listed security requirements seem very important for annex G. Technically, what is less clear to me is what kind of interrelation exists between two administrative domains: Can we assume some sort of passwords to exist between administrative domains such that some sort of "subscription-like" security mechanisms could be applied? Or is an administrative domain rather an isolated environment that does not share certain (long-term) secrets with anybody else? In this case public-key techniques seem more appropriate. My impression on the understanding of the annex G definitions is that an administrative domain very closely resembles a so-called security domain; i.e. a set of administered elements conforming to a certain security policy. Thus, there is a certain level of trust within a domain but not always between domains. A common technology applied today to shield a security domain is using a firewall with network address translation and proxy. Border elements are in the position of an edge device on the security domain perimeter and should offer certain firewall functionality such as protecting the security domain and hiding zone topology information. A first approach shown in annex G is the option that a border element releases only very restricted template information about its zone/domain. Finally, going back to Jan's statement. From following past annex G discussion from the far distance so far, my impression is that most of the discussion has been focussing more on the scope and scenario issues while the protocol details (such as using RAS and/or something else) was not of primary concern. Unfortunately, unless it is clear what signaling protocols are actually used for annex G, it is a bit difficult to progress substantially on the related security issues. martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

-----Original Message----- From: Jim Toga [SMTP:jim.toga@intel.com] Sent: Dienstag, 13. Oktober 1998 19:10 To: Euchner Martin; Mailing list for parties associated with ITU-T Study Group 16; ITU-SG16@mailbag.cps.intel.com Cc: voip@imtc.org; TIPHON@list.etsi.fr; Klasen Wolfgang Subject: Re: Gk-GK Call signalling - security????

Martin,

I would corroborate Senthil's point. All of the capabilities to utilize H.235 functionality (including the use of 'external' mechanisms such as TLS or IPSec) are indended to be available to annex G signaling.

Some (ok much...) of the procedural description is not included yet. If anyone sees any specific barriers in accomplishing this, please speak up.

jimt.

...

I believe ITU will in fact provide the needed security features for inter-gatekeeper communication. The determined version of Annex G already has an authentication field in the zone exchange messages. However,

At 11:50 AM 10/13/98 -0400, Sengodan Senthil NRC/Boston wrote: providing such fields does not guarantee interoperability unless specific security mechanisms are mandated - which the ITU will probably not get into. This work - of specifying security profiles for interoperability - falls within IMTC VoIP and TIPHON.

...

Regarding Jan's comment, as Gur alluded to, Annex G's immediate focus is

address resolution. Other features, I believe, will be added after this is tackled.

...

- Senthil

Senthil Sengodan Nokia Research Center, Boston ---------- From: Euchner Martin To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin Subject: RE: Gk-GK Call signalling - security???? Date: Tuesday, October 13, 1998 3:11PM

I'm somewhat confused about the statement that Annex G security issues

are

...

not in the scope of ITU's work but inTiphon/IMTC.

...

From my impression of the recent ITU-T SG16 meeting in Geneva, the demand for better security regarding the inter-GK scenario was very clearly expressed. For obvious reasons, ITU's work on defining enhancements in annex G implies to address also the security issues in an appropriate way. The requirements section in annex G lists already several security requirements, so this work item is already part of their work. Of course, there is no real need to invent new security solutions for annex G in case other standards bodies have some appropriate technology available that could be referenced for example. Whatever security solutions will come out, the result could very smoothly be described and added to the H.235 security recommendation. Note, that current H.235 provides already (some) security solutions to H.225.0; thus, annex G security features seem a natural enhancement to this work.

martin.

----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

...

-----Original Message----- From: gur kimchi [SMTP:gur.kimchi@ETSI.FR] Sent: Dienstag, 13. Oktober 1998 14:21 To: TIPHON@LIST.ETSI.FR Subject: Re: Gk-GK Call signalling - security????

Hi Jan,

I attended the Q.13 meeting also - and The scope of Annex G is very well defined: it is attempting to introduce new mechanisms where none exist today. We could argue for hours whether there are inter-gk call-singalling mechanism today, and well, there are (H.225) - the main missing point there is security - which the ITU will not define anyway - but TIPHON (and VoIP).

e.g. the new mechanisms are Zone information Exchange.

- gur

-----Original Message----- From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE] Sent: 13 October 1998 13:40 To: TIPHON Subject: Gk-GK Call signalling

Hello All, I participated in the SG 16 meeting in Geneva in september.

One thing that suprised me was that the ongoing work with Annex G (GK-GK signalling) did not consider call control, only the RAS signalling.

When I asked why, they did not understand why any change is required. After a while they understood that something could be needed, but it was postponed to future releases of H.323.

Future releases must be version 4 or something (around year 2001 or later ??).

The conclusion is then (looking on TIPHON project plan) that H.323 can't be used between Gatekeepers in TIPHON compliant system.

The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended subset of H.323?

/Jan Holm Ericsson Telecom AB

------------------------------------------------------------------- ATTENTION !!! TIPHON list distribution parameters have changed: ==> if you REPLY to a TIPHON mail your mail will be sent to the original sender only. ==> if you use REPLY ALL your mail will be sent to TIPHON and to the original sender. -------------------------------------------------------------------

------------------------------------------------------------------- ATTENTION !!! TIPHON list distribution parameters have changed: ==> if you REPLY to a TIPHON mail your mail will be sent to the original sender only. ==> if you use REPLY ALL your mail will be sent to TIPHON and to the original sender. -------------------------------------------------------------------

***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************