September 1999 - sg16-avd - lists.packetizer.com

Queries on RAS security !!
by Aparna Saha 20 Sep '99

20 Sep '99

Hi Jim, I have a few queries related to H.235, specifically, RAS security. This is regarding the RAS procedures for authentication . During the GRQ-GCF exchange, the security info ( the secret key and the algorithmId ) gets established with the GK. For the subsequent RRQ, how does the GK relate the RRQ with the info stored ? Is there any mechanism for refreshing keys in RAS ? Thanks and regards, Aparna.

1 0

APC Document Numeber
by Noriko Hosokawa 19 Sep '99

19 Sep '99

Dear Mr. Francois Audet In response to your request, APC-1654 has been allocated to your contribution. APC-1654 > Title: ISO/IEC 11571 addressing in H.323 Annex V > Source: Nortel Networks Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 1656 ---------------------------------------------------------------------------- ----

1 0

Re: Questions on H.235
by Douglas Clowes 19 Sep '99

19 Sep '99

At 12:01 1999-09-17 +0200, Euchner Martin wrote: >Douglas, > >as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security. > > >On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols). > >For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement. OK, I forgot the multicast case. However, the generalId should, IMHO, be either that of the recipient (unicast) or not present (multicast), rather than that of the sender as shown. >Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented. While you're at it, 10.3.2 method for forming a key from a password is embarrassingly weak. A short password ('X' for example) produces a key which is mostly zero bits. Even a longer pass phrase will prod use a key with high order bits set to zero in each byte, and similar characteristics reducing a keys strength significantly. Most credible schemes would use a hash function (MD5 or SHA1) over the pass phrase, and would not fill out the pass phrase with zeroes. The amount of entropy in such a key will be very low, and one should not use such a key for bulk encryption. To do so would provide an attacker with a large amount of cryptotext, some of which will be known, enabling a known-cryptotext attacks. An additional key generation/exchange mechanism should be employed. >Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2. In UDP based protocols, strict sequencing is not possible, because message order and delivery and duplication are not guaranteed. An eavesdropper can easily generate a sequence number in the range, so a legitimate message will duplicate an illegitimate message sequence number. A signature is a more secure check. >Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J. Good. It should not be part of H.235 either. >A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature. I understand that HMAC-xxx-96 gives away less information on the key, and should be preferred for a long term password based mechanism. >Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Trouble is that, for a time, neither party knows that a message is lost. If I send you an xRQ and you send me a new random in the xCF, which random do you use to check my next message? It needs to be different depending on whether the xCF was lost or not. If you use the new one, and my next transmission is a retransmit of the original xRQ, will you reject it because it doesn't use the new random? You will have to check both. If I send you an xRQ that lives for a while in a router queue, receive a new random and use it in a message that arrives at you before the earlier one (out of order reception happens) and you check it against the new random, it matches. When the first message arrives, it has the old random. Will you reject it or ignore it? Either way, will I understand that I have to recompute it and send it again. If you reject it, I may fail the operation. If you ignore it, I may resend the same bit-pattern with the old random. >Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile). Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and 2402). I agree with you there, but wonder if it's better to sign the entire message, just the DH component, or both. Regards, Douglas >Regards, > >Martin.

1 0

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first draft]]] ]
by Roy, Radhika R, ALARC 17 Sep '99

17 Sep '99

Hi Ed: I appreciate your reply. To support wireless handset in pure H.323 environment, we may think couple of scenarios: 1. Wireless LAN, 2. H.323 Wireless handset (2a. WAU that is NOT aware of H.323, 2b. WAU that is H.323-aware), and 3. (Non-H.323) wireless handset interfacing an H.323 system via a IWF (GW). In addition, we also have situations what mobile IP [IETF] is dealing with. I would call this as scenario 4. H.323 needs not to be aware of the radio link environment in scenarios 1 and 2a and, the H.323 mobility solution is independent of the lower link layer. The general H.323 mobility problem needs to address intra-zone, inter-zone, and inter-domain mobility management (change of point-of-attachment [network, zone, domain]) before bringing the radio link issues. In this context, we need to address (GK) discovery, registration, location updates, call establishment, roaming, and handover in the H.323 layer. We will find that H.323 needs extensions to support mobility. In scenario 2b (I guess is that your contribution is primarily concerned with) is a special case. That is, WAU is both H.323- and radio link-ware. As a result, your contribution is proposing some extensions in H.323 to deal with this situation. This is a very interesting situation that we need to consider as a special case. What I would suggest that let us address this situation in the light of cases 1, 2a, and 4 where the H.323 mobility solution is provided without being aware of the radio link. Then, we need to address scenario 4: For example, cellular-PSTN and H.323 Mobile system interworking. We have drafted this requirement as the "INTERWORKING." In this context, we might see that H.323 may need more extensions to support mobility. That is, the radio traffic that you are concerned with may be dealt later once we see that we have solved the mobility problems in the H.323 layer. Then, we can apply it in some specific scenarios like the radio environment as you have started (scenario 2b). The point is that the general solution should also be capable to solve the problem that you have undertaken (if needed some extensions can be made). The question is: what would be the approach to solve the H.323 mobility in the H.323 layer? The paper of W. Liao published in the INFOCOM'99 conf provides some ideas. This paper might be a good start to solve the mobility problem in the H.323 layer. However, we have to go a long way to meet all requirements of mobility in H.323 beyond what has been discussed in this paper. As APCs indicated, more contributions (e.g., AT&T, Lucent, others) are coming in the upcoming Red Bank (Oct 18-22) conf. With respect to the MC (not necessarily MCU) to provide the handoff, it can be placed with the GK, GW, or other entities (e.g., WAU) as needed. This might be an option for implementations. However, handoff will be in the H.323 layer (Please also see the above paper). Then, we can translate this into the corresponding radio layer. The handoff in the radio layer can be implementation specific. In fact, we might need all functionalities that you have proposed in the radio layer. Again, your contributions have provided valuable insights to address H.323 mobility problems. Hope this will help. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Wednesday, September 15, 1999 10:44 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > draft]]]] > > Hi Roy, > > Just to take this off-line for the moment, but only for clarification. > > If we support a H.323 wireless handset in a pure H.323 environment. Where > do > you see the AIR interface access to the H.323 network? In the context > of a pure IP mobile network without interworking. What I mean is do > we only provide a BTS access to the network run all the radio traffic > through > the > network. Or do we provide something like a RAN (WAU) > to handle the radio traffic on the edges?. > > The radio traffic that I been mentioning is not directly related to H.323 > call > setup > that is Mobile Terminal paging and all radio channel management functions. > > But, whether we use a BTS or WAU for wireless access to the IP > network will greatly influence the way we do handovers in a pure > IP network. This does not affect roaming. > > One suggestion you provided on handover was using the MCU, > I could work with that. But something like the WAU can provide > the MCU function in the edges between H.323 (MT to MT), or MT to PC. > Since the only device that requires handover is the wireless > Mobile Terminal (MT). > > Best Regards, > > Ed > > > "Roy, Radhika R, ALARC" wrote: > > > Hi Ed: > > > > I understand your approach. Your approach is an INTERWORKING between the > > H.323 and PSTN-Wireless networking environment. > > > > First, we need to solve all mobility problems in the H.323 layer. Once > we > > solve H.323 mobility problems in a transport independent way, we can > then > > implement that solution in a special "INTERWORKING" environment: H.323 > > system (e.g., IP network) with an interface (e.g., WAU) to the > PSTN-wireless > > system. > > > > There are two steps: 1. Solve the mobility problems in H.323 layer > > (Terminal, User, and Service Mobility) and 2. Implement the H.323 > mobility > > problems in specific networking environments for "Interworking". > > > > The H.323 mobility problems solved in the H.323 layer should be > applicable > > for all circumstances. For example, > > > > 1. Mobile IP (IETF) > > 2. PSTN-wireless (PLMN) > > 3. Emerging mobile and wireless networks > > > > That is, the general H.323 mobility solution will also complement the > > solution that you are proposing. There may be some differences in > approach > > that you are proposing, but it (H.323 mobility) will achieve the same > > objectives what your contribution is up to. In fact, I welcome your > > contribution because it has provided us valuable insights of the > mobility > > problems in the context of H.323 and PSTN-Wireless networking > environment. > > > > Best regards, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Tuesday, September 14, 1999 9:21 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > > darft]]]] > > > > > > Thank you all for your comments. > > > > > > Roelands Marc wrote: > > > > > > > Hi all, > > > > > > > > I am struggling with some conceptual problems concerning the Annex-H > > > > proposal of Edgar Martinez, feeling that this has some commonality > with > > > the > > > > remarks of Roberto Winkler and Simon Binar on it. IMHO, the proposed > > > > architecture, and especially the WAU and the GK, are mixing all > kinds of > > > > mobility related functionality in a single, strongly coupled, > > > > do-it-all-in-H.323 layer, involving radio access up to H.323 > application > > > > layer. > > > > > > I believe there is a clear separation of functional requirements > between > > > the > > > radio control > > > functions of the WAU, and the Network control and Mobility Management > > > functions > > > in the GK. Would it make everyone happy if we called WAU RAN? For > network > > > efficiency > > > the WAU would handle all the Radio link resources at the edges, > thereby > > > preventing > > > traffic overloading on the network. > > > > > > > > > > > > > > > Specifically, I have some difficulties with the following: > > > > > > > > 1. No clear division in terminal and user mobility aspects in the > basic > > > > H.323 architecture is taken as a starting point: shouldn't there be > > > > specified somewhere in general, in conjunction with the H.323 set of > > > > protocols, that IP addresses represent terminals in an IP network, > and > > > that > > > > users can only be represented by logical names from a directory > (i.e. > > > > aliases), and whether an "endpoint" is a user or a terminal? If this > is > > > > decided on, the H.323 registration procedure is just what is needed > to > > > have > > > > user mobility, by dynamically associating a logical user name with > one > > > or > > > > multiple terminals upon user request. With terminals identified by > IP > > > > addresses, terminal mobility would further be strictly a network > access > > > > problem. > > > > > > > > 2. Annex-H is supposed to handle user and service mobility, so why > would > > > the > > > > handover problem, as any other terminal mobility related problem, be > > > handled > > > > here instead of independently in Annex-I? > > > > > > In the second day of the Ad-hoc SG-16 meeting, some of us discussed, > > > the possibility of combining Annex H and I, if no contributions came > > > in for Annex-I. > > > > > > > > > > > > > > > > > > 3. Mobility is not an issue in H.323 alone, e.g. consider roaming > and > > > > handover for a connection-oriented data application, so why should > it be > > > > handled in H.323 on its own? Or put otherwise, is H.323 support > really > > > > required on a terminal in order to be able to roam, as a user of > some > > > > service, or as a terminal accessing a network? > > > > > > I specifically asked where do we focus, and was told to assume that > > > there will be H.323 wireless sets. And focus only on H.323 terminals, > > > to get the work started. And that other types of terminals would > > > be handled separately. > > > > > > > > > > > > > > > 4. Although the proposal pays attention to the identification of > several > > > > degrees of locality for roaming and handover, solving all control > issues > > > > (radio access, IP-networking, etc.) in a single application layer > still > > > > leads to both resource sub-optimality and complexity. E.g. why > should > > > the > > > > WAU be aware of anything having to do with (user) mobility > management? > > > > > > I believe there is a misunderstanding the mobility management > > > and services is handle by in the network e.g, GK. > > > The Radio Resource management is at the edges which is aware > > > of the terminals radio links. > > > > > > > > > > > > > > > Instead I would propose to use an approach of highly independent > layers, > > > > following good Internet tradition, and solving the problems as > locally > > > as > > > > possible (both geographically and architecturally). Here's the > layers I > > > > think at least should be distinguished: > > > > > > > > - MAC level: terminal micro-mobility across radio cells, ethernet > > > segments, > > > > etc. can exist without any consciousness of this at the IP level > (e.g. > > > using > > > > wireless LAN tunneling techniques); > > > > > > > > - IP network level: terminal macro-mobility across the Internet > should > > > be > > > > invisible to higher layers (e.g. by means of Mobile IP v4 or v6 and > the > > > > improvements suggested for delay-sensitive traffic like RTP streams: > > > Mobile > > > > IP HAWAII, or draft-elmalki-mobileip-fast-handoffs-01 to name but a > few; > > > > note that route optimization is also worked on in this area); > > > > > > > > - "terminal real-time signaling" application level: the level where > > > > telephony and MM signaling like H.323 can be placed (restricting GW > and > > > GK > > > > functionality to strictly this level); here Annex-H might define > > > transport > > > > for additional parameters and vertical signaling, useful for serving > the > > > > "user services" application level (below); at this lowest > application > > > level > > > > packet to circuit switched network boundaries may be crossed (cf. > the > > > > evolving traditional telephony networks vs. the Internet); > > > > > > > > - "user services" application level: user and service mobility takes > > > place > > > > here, making use of a network- (and H.323) independent naming system > > > > (directories using e.g. DNS, LDAP schemas, etc.) and e.g. back-end > > > services, > > > > "behind" or "on top of" one or several GKs for realizing UM, user > > > mobility > > > > support for a larger scope than just H.323, smart user assistance, > etc.. > > > > > > > > This approach has not only the general advantage that every layer > can > > > evolve > > > > technically independent of all others, it also has the specific > > > advantage > > > > that it realizes true consolidation of mobility for telephony and > > > > traditional data applications. > > > > > > > > As a last point, it is not clear to me at which of these levels > H.450 > > > would > > > > belong. As it is specified now it is on top of H.323, but suppose > one > > > would > > > > like to adopt a service provision model where a user could subscribe > to > > > a > > > > telephony-related service , wouldn't it be nice then to be able to > offer > > > > this across different telephony technologies (a bit like where IN > aims > > > at)? > > > > A comparison to using a HTTP service control layer (Annex-K) might > be > > > > interesting here. > > > > > > > > I cannot imagine that these fundamental issues where not previously > > > > discussed in ITU-T SG16 or Tiphon WG7, so if anyone can give me some > > > > arguments why an approach as I tried to describe here could not be > > > followed, > > > > I would be glad to know about it. > > > > > > Your comments are very good and your suggestions are very applicable > to > > > what we are working on, but unless a contribution is presented to the > > > proper > > > groups e.g., ITS-sg16 q13/14 they would just fade away. ITU > > > recommendations > > > are contribution driven. > > > > > > Best Reagrds, > > > Ed > > > > > > > > > > > > > > > Regards, > > > > Marc Roelands > > > > Siemens ICN Atea > > > > Atealaan 34 > > > > B-2200 Herentals > > > > Belgium > > > > Tel.: +32 14253965 > > > > Fax: +32 14222994 > > > > E-mail: marc.roelands(a)siemens.atea.be > > > > > > > > -----Original Message----- > > > > From: Roberto Winkler [mailto:wnk@FUB.IT] > > > > Sent: Tuesday, September 14, 1999 10:34 AM > > > > To: TIPHON_WG7(a)LIST.ETSI.FR > > > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > > > darft]]]] > > > > > > > > Jin, Edgar, > > > > > > > > If I may try to give my 2 cents in this discussion, I think that the > > > > problems/weakness of 3GPP considered systems (which Edgar is > speaking > > > > about) cannot match with the faults identified by Lucent's > contribution, > > > > which is focused on the unique issue of R99 terminal support in the > All > > > IP > > > > R00 network. Considering these 3GPP contributions does not help in > > > > understanding Edgar's point of view. > > > > I have already sent a few e-mails to comment the proposed mobile > H.323 > > > > architecture and would like to summarize here my view, hoping to get > > > > reactions: > > > > - the role and reason for being of WAU is unclear (as TIPHON is > focused > > > on > > > > user and service mobility, why worry about the access medium ?) > > > > - the redefinition of several RAS channel messages is confusing (why > > > does > > > > the RAS channel terminates at WAU ?) > > > > - protocol stacks and interface definitions are missing from the > > > picture. > > > > > > > > best regards > > > > > > -- > > > Edgar Martinez - Principal Staff Engineer > > > Email mailto:martinze@cig.mot.com > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: RTCP sender reports - when to use?
by Orit Levin 17 Sep '99

17 Sep '99

Hi Henri! The answer is ... the RTCP channel is bi-directional even when opened to be used for A->B RTP media stream only. If A wants to send a stream going A->B, A originates the OLC procedure. During this procedure B's RTP port, B's RTCP port and A's RTCP ports are exchanged between the sides. For the same "kind" of media stream (such as "voice" or "video) usually B would like to send a media stream going A<-B belonging to the same H.245 session opened above. In this case B will issue OLC advertising the same B's RTCP port already used within this session. As the result, two media unidirectional RTP channels and a single common bi-directional RTCP channel will be opened within the same H.245 session. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: henri.maenpaa(a)NOKIA.COM <henri.maenpaa(a)NOKIA.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, September 16, 1999 5:05 AM Subject: RTCP sender reports - when to use? >Hi, > >Could somebody clarify a few things for me... > >Say, there's a call between A and B in H.323. RTP sessions for both stream >directions are totally independent of each other, right? (except with T.120 >channel a bidirectional one can be used). > >Let's concentrate on RTP session where stream goes from A to B. >This one RTP session is a unidirectional channel. Is the related RTCP >channel also a unidirectional channel, but to opposite direction? >So, if this is true, how can we use sender reports (SR) in H.323? >Am I right when I assume that only way sender reports can be used in H.323 >is with a T.120 bidirectional channel (when RTCP channel would probably be >bidirectional also)? > >Cheers, >Henri >

2 1

Re: H.235 Control Channel
by Euchner Martin 17 Sep '99

17 Sep '99

Anseem, the secure logical channel does not have its own data type. It is merely an abstract notion telling that the OLC operates in a certain mode. It is flagged by KeyProtectionMethod.secureChannel. The security logical channel is a separate security connection parallel to the unprotected OLC; e.g., TLS, SSL,... The security logical channel is used to establish authentication and exchange key material. This key material is used by the master then as a key encryption key for secure transmission of the media key (within the OLC). I'm currently preparing an updated version of H.235v2, that will be presented at the upcoming Rapporteurs meeting in October. Regards, 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 | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Aseem Agarwal [SMTP:aseem@TRILLIUM.COM] Sent: Friday, September 17, 1999 2:54 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.235 Control Channel Hi All H.235 specifies opening up a secure logical channel. In this mode of operation the regular H.245 control channel may operate in unsecured mode. I have the following doubts about this procedure: 1. What is the "DataType" value used in the OpenLogicalChannel message exchanged for the secure channel ? Section 8.2 specifies that "encryptionData" may be used, but elsewhere in the document the channel is referred with the value "h235Control" which is yet another value for dataType. 2. How does the exchange of encryption related information happen on the secure logical channel ? Does this happen in the data plane ? OR this new logical channel serves as a new control channel and the key exchange happens using EncryptionUpdate messages ? H.235 does not clearly specify the sematics/functionality of this logical channel. IMHO, many loose ends have been left behind which may result in different implementations. Comments/feedback welcome. Also, please let me know when we can expect the updated/next version of H.235 document. Regards, aseem(a)trillium.com

1 0

Re: Questions on H.235
by Euchner Martin 17 Sep '99

17 Sep '99

Douglas, as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security. On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols). For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement. Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented. Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2. Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J. A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature. Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile). Regards, 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 | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU] Sent: Friday, September 17, 1999 1:41 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Questions on H.235 At 12:28 1999-09-16 +0200, Euchner Martin wrote: >The generalID of the GK could be configured in the endpoint or could be made available by some other means out of band. >In the next version of H.235 (i.e. H.235v2) the ClearToken will feature both the source and the destination identifiers. Then, the EP will learn the generalID of the GK. The crucial point is still the initial GRQ which either comes with some reduced security when not including the GK-ID or with increased security but also increased complexity when the EP has to know the GK-ID by some other means a priori. > >The basis for the H.235 security protocols are ISO/IEC 11770-3 (7.2) and ISO/IEC 9798-2 (5.1.2) / 9798-4 (5.1.1). These security protocols always carry the destination address/identification in their message in order to counter reflection attacks (a special variant of a replay attack). Thus, the generalID_A in the phase I reply message is correct. By this logic, and pre-knowledge of generalID_b, message 1 of phase 1 should contain generalID_b in the CryptoToken. This not only counters reflection (replay against the same receiver) but the more general case of replay against a different receiver. The ClearToken on the other hand, could contain the identifier of the sender, so that the receiver can identify the correct cryptographic material to use to verify the signature in the CryptoToken (unless that information appears elsewhere in the message). It is a good idea to include both identifiers in the ClearToken within the signed CryptoToken. Have I missed the H.235v2 draft somewhere? Are there APCs addressing this (and other) change(es), or are you alluding to future APCs? While I have a number of security/cryptography texts on my bookshelf, the referenced ISO/IEC ones are not among them. I only have the ITU-T and joint ISO-ITU-T (X-series) ones. >2. Man-in-the-middle attacks: The security protocol shown in Fig.1/H.235 is secure against man-in-the-middle attacks as long as the Diffie-Hellman tokens are signed with the private key or are authenticated by a cryptographic MAC. The security protocol is secure even when an attacker intercepts parts or the entire message. Basically, this is stated by the Diffie-Hellman and discrete logarithm assumptions that someone cannot break the crypto system by having access to all messages exchanged on the wire. Thus, no threat arises by snooping these parameters. >The Timestamp within the ClearToken is included in order for the recipient to verify the CryptoToken. I think that it is open to replay against another receiver, at least for denial of service, while the timestamp is fresh. The receiver needs to create state and an eavesdropper could replay the message against all other gatekeepers in the domain. If the initial (unicast) GRQ is unsuccessful and the real gateway issues a new GRQ (with possibly same or different DH conmonent) to such a gatekeeper that is waiting for phase 2, what will it do? Changing the generalID in the CryptoToken of message 1 to that of EPB will stop that. >3. Please note, that the Diffie-Hellman procedure appears twice in H.235 in different contexts: The first usage of Diffie-Hellman key exchange is during RAS (as shown in Fig1/H235) where the agreed DH-secret is to encrypt the XORed sequence number (see B.4.2 of H.235) It is used in message 3 of Figure 1 also, which is what I think is being described in B.4.2. I don't like the mechanism described in B.4.2 for the folowing reasons. Firstly, requiring the transmission of the ciphertext of specified cleartext opens up to the known cleartext attack. If the contents are known by both parties, then a keyed hash makes more sense. Secondly, it relies on the success of a previous exchange. If the latest random_b were returned in an ACF which was not delivered, then all subsequent messages (including the retransmission of the ARQ) would fail authentication. It would be better to send a new timestamp_a and random_a with each request, and the keyed HMAC (e.g. HMAC-SHA1-96) of that with the DH_secret (and gatekeeperID if you like, but I don't think it adds anything). My personal favorite is to include a ClearToken in the message, which contains the timestamp of the sender, possibly a random number or sequence, and HMAC the entire message with the shared secret. The HMAC can go in the icv (for those messages that have it - H.225.0 RAS and Annex G). The preferred solution, more widely applicable, is to place the HMAC in a CryptoToken with an OID for the purpose (as in H.225.0 Annex J). >Another use of the Diffie-Hellman key agreement scheme is applied during call signaling. Here, the entities involved agree to a common shared secret (i.e. the DH-key) from which a key encryption key (master key) is derived. This master key is used by the H.323 master in order to securely transmit and update the media encryption key. Note that these methods appear to provide protection for RAS messages and media, but not for call signalling, where the parties to communication have had no prior contact, unless a certificate based public key system is used. Regards, Douglas

1 0

APC Document number
by Noriko Hosokawa 16 Sep '99

16 Sep '99

Dear Mr. Patrick Luthi In response to your request, APC-1653 has been allocated to your contribution. APC-1653 Source: PictureTel $B!! (BTitle : Proposed text for G.722.1 capabilities in the $B!!!!!!!!!! (BH.323 Implementor's Guide Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 1655 1656 ---------------------------------------------------------------------------- ----

1 0

H.235 Control Channel
by Aseem Agarwal 16 Sep '99

16 Sep '99

Hi All H.235 specifies opening up a secure logical channel. In this mode of operation the regular H.245 control channel may operate in unsecured mode. I have the following doubts about this procedure: 1. What is the "DataType" value used in the OpenLogicalChannel message exchanged for the secure channel ? Section 8.2 specifies that "encryptionData" may be used, but elsewhere in the document the channel is referred with the value "h235Control" which is yet another value for dataType. 2. How does the exchange of encryption related information happen on the secure logical channel ? Does this happen in the data plane ? OR this new logical channel serves as a new control channel and the key exchange happens using EncryptionUpdate messages ? H.235 does not clearly specify the sematics/functionality of this logical channel. IMHO, many loose ends have been left behind which may result in different implementations. Comments/feedback welcome. Also, please let me know when we can expect the updated/next version of H.235 document. Regards, aseem(a)trillium.com

1 0

Re: Questions on H.235
by Douglas Clowes 16 Sep '99

16 Sep '99

At 12:28 1999-09-16 +0200, Euchner Martin wrote: >The generalID of the GK could be configured in the endpoint or could be made available by some other means out of band. >In the next version of H.235 (i.e. H.235v2) the ClearToken will feature both the source and the destination identifiers. Then, the EP will learn the generalID of the GK. The crucial point is still the initial GRQ which either comes with some reduced security when not including the GK-ID or with increased security but also increased complexity when the EP has to know the GK-ID by some other means a priori. > >The basis for the H.235 security protocols are ISO/IEC 11770-3 (7.2) and ISO/IEC 9798-2 (5.1.2) / 9798-4 (5.1.1). These security protocols always carry the destination address/identification in their message in order to counter reflection attacks (a special variant of a replay attack). Thus, the generalID_A in the phase I reply message is correct. By this logic, and pre-knowledge of generalID_b, message 1 of phase 1 should contain generalID_b in the CryptoToken. This not only counters reflection (replay against the same receiver) but the more general case of replay against a different receiver. The ClearToken on the other hand, could contain the identifier of the sender, so that the receiver can identify the correct cryptographic material to use to verify the signature in the CryptoToken (unless that information appears elsewhere in the message). It is a good idea to include both identifiers in the ClearToken within the signed CryptoToken. Have I missed the H.235v2 draft somewhere? Are there APCs addressing this (and other) change(es), or are you alluding to future APCs? While I have a number of security/cryptography texts on my bookshelf, the referenced ISO/IEC ones are not among them. I only have the ITU-T and joint ISO-ITU-T (X-series) ones. >2. Man-in-the-middle attacks: The security protocol shown in Fig.1/H.235 is secure against man-in-the-middle attacks as long as the Diffie-Hellman tokens are signed with the private key or are authenticated by a cryptographic MAC. The security protocol is secure even when an attacker intercepts parts or the entire message. Basically, this is stated by the Diffie-Hellman and discrete logarithm assumptions that someone cannot break the crypto system by having access to all messages exchanged on the wire. Thus, no threat arises by snooping these parameters. >The Timestamp within the ClearToken is included in order for the recipient to verify the CryptoToken. I think that it is open to replay against another receiver, at least for denial of service, while the timestamp is fresh. The receiver needs to create state and an eavesdropper could replay the message against all other gatekeepers in the domain. If the initial (unicast) GRQ is unsuccessful and the real gateway issues a new GRQ (with possibly same or different DH conmonent) to such a gatekeeper that is waiting for phase 2, what will it do? Changing the generalID in the CryptoToken of message 1 to that of EPB will stop that. >3. Please note, that the Diffie-Hellman procedure appears twice in H.235 in different contexts: The first usage of Diffie-Hellman key exchange is during RAS (as shown in Fig1/H235) where the agreed DH-secret is to encrypt the XORed sequence number (see B.4.2 of H.235) It is used in message 3 of Figure 1 also, which is what I think is being described in B.4.2. I don't like the mechanism described in B.4.2 for the folowing reasons. Firstly, requiring the transmission of the ciphertext of specified cleartext opens up to the known cleartext attack. If the contents are known by both parties, then a keyed hash makes more sense. Secondly, it relies on the success of a previous exchange. If the latest random_b were returned in an ACF which was not delivered, then all subsequent messages (including the retransmission of the ARQ) would fail authentication. It would be better to send a new timestamp_a and random_a with each request, and the keyed HMAC (e.g. HMAC-SHA1-96) of that with the DH_secret (and gatekeeperID if you like, but I don't think it adds anything). My personal favorite is to include a ClearToken in the message, which contains the timestamp of the sender, possibly a random number or sequence, and HMAC the entire message with the shared secret. The HMAC can go in the icv (for those messages that have it - H.225.0 RAS and Annex G). The preferred solution, more widely applicable, is to place the HMAC in a CryptoToken with an OID for the purpose (as in H.225.0 Annex J). >Another use of the Diffie-Hellman key agreement scheme is applied during call signaling. Here, the entities involved agree to a common shared secret (i.e. the DH-key) from which a key encryption key (master key) is derived. This master key is used by the H.323 master in order to securely transmit and update the media encryption key. Note that these methods appear to provide protection for RAS messages and media, but not for call signalling, where the parties to communication have had no prior contact, unless a certificate based public key system is used. Regards, Douglas

1 0