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(a)mailbag.cps.intel.com
> Cc: voip(a)imtc.org; TIPHON(a)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.
>
> At 11:50 AM 10/13/98 -0400, Sengodan Senthil NRC/Boston wrote:
> >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,
> 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(a)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 ***
> *****************************************************
