1、 International Telecommunication Union ITU-T H.460.22TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (01/2007) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Supplementary services for multimedia Negotiation of security protocols to protect H.225.0 call signalling
2、 messages ITU-T Recommendation H.460.22 ITU-T H-SERIES RECOMMENDATIONS AUDIOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.219 Transmission multiplexing and synchronization H.220H.229 Systems aspects H.230H.2
3、39 Communication procedures H.240H.259 Coding of moving video H.260H.279 Related systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audiovisual and multimedia services H.350H.359 Quality of service architecture for audiov
4、isual and multimedia services H.360H.369 Supplementary services for multimedia H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols and procedures H.500H.509 Mobility for H-Series multimedia systems and services H.510H.519 Mobile multimedia
5、collaboration applications and services H.520H.529 Security for mobile multimedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H.549 Mobility interworking procedures H.550H.559Mobile multimedia collaboration inter-working procedures H.56
6、0H.569 BROADBAND AND TRIPLE-PLAY MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. H.460.22 (01/2007) i ITU-T Recommendation H.460.22 Negotiation of security protocols to protect H.225.0 call sign
7、alling messages Summary ITU-T Recommendation H.460.22 defines a security negotiation mechanism for H.225.0 call signalling. The negotiated security mechanism between two entities is to be applied for H.225.0 call signalling messages before initiating a call establishment procedure. Detailed negotiat
8、ion procedures, which provide the necessary security interoperability among H.323 systems, are specified in this Recommendation. The syntax of the security capability parameters in call signalling messages is also specified. Source ITU-T Recommendation H.460.22 was approved on 13 January 2007 by ITU
9、-T Study Group 16 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. H.460.22 (01/2007) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T)
10、is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years
11、, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necess
12、ary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However,
13、 the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equiv
14、alents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a cl
15、aimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had
16、 not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int
17、/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. H.460.22 (01/2007) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 1 4 Abbreviations and acronyms 2 5 Conventions 2 6 N
18、egotiation description. 2 6.1 Call establishment security. 3 6.2 Negotiation of security mechanism 3 7 Feature description securityProtocolNegotiation . 6 7.1 tlsSecurityProtocol . 7 7.2 ipsecSecurityProtocol. 8 ITU-T Rec. H.460.22 (01/2007) 1 ITU-T Recommendation H.460.22 Negotiation of security pr
19、otocols to protect H.225.0 call signalling messages 1 Scope This Recommendation specifies the security negotiation mechanism for H.225.0 call signalling message exchanges. The main goals include: 1) Secure selection of the security mechanism. Otherwise, the procedure of negotiation is vulnerable to
20、certain attacks such as malicious manipulation or bidding-down attacks. The entire RAS message shall be protected during the negotiation procedure. 2) Involved H.323 entities shall determine mutually agreed security protocols without requiring additional round trips. 3) Entities involved in the nego
21、tiation procedure shall be aware of the result of the negotiation, such as success or failure. 4) The negotiation procedure should not cause any additional burden to the involved entities. 2 References The following ITU-T Recommendations and other references contain provisions which, through referen
22、ce in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most re
23、cent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T H.225.0 ITU-T R
24、ecommendation H.225.0 (2006), Call signalling protocols and media stream packetization for packet-based multimedia communication systems. ITU-T H.235.0 ITU-T Recommendation H.235.0 (2005), H.323 security: Framework for security in H-series (H.323 and other H.245-based) multimedia systems. ITU-T H.32
25、3 ITU-T Recommendation H.323 (2006), Packet-based multimedia communications systems. ITU-T H.460.1 ITU-T Recommendation H.460.1 (2002), Guidelines for the use of the generic extensible framework. IETF RFC 4302 IETF RFC 4302 (2005), IP Authentication Header. IETF RFC 4303 IETF RFC 4303 (2005), IP Enc
26、apsulating Security Payload (ESP). IETF RFC 4346 IETF RFC 4346 (2006), The Transport Layer Security (TLS) Protocol Version 1.1. 3 Definitions This Recommendation does not define any terms. 2 ITU-T Rec. H.460.22 (01/2007) 4 Abbreviations and acronyms This Recommendation uses the following abbreviatio
27、ns and acronyms: ACF Admission Confirmation ARJ Admission Reject ARQ Admission Request ASN.1 Abstract Syntax Notation One GCF Gatekeeper Confirmation GEF Generic Extensible Framework GRQ Gatekeeper Request IPSec Internet Protocol Security LCF Location Confirmation LRJ Location Reject LRQ Location Re
28、quest MCU Multipoint Control Unit RAS Registration, Admission and Status RCF Registration Confirmation RRJ Registration Reject RRQ Registration Request RTP Real-time Transport Protocol TCP Transmission Control Protocol TLS Transport Layer Security 5 Conventions In this Recommendation, the following
29、conventions are used: “Shall“ indicates a mandatory requirement. “Should“ indicates a suggested but optional course of action. “May“ indicates an optional course of action rather than a recommendation that something take place. 6 Negotiation description The protection of ITU-T H.225.0 call signallin
30、g messages is very important for the security of an ITU-T H.323 system. In small networks, network administrators can ensure that all H.323 entities use the same security protocol. However, in large networks, such as where endpoints are distributed in different network domains, a calling endpoint ma
31、y not know in advance the security protocol supported by the called endpoint. Therefore, it is necessary for the two endpoints to negotiate the security mechanism for H.225.0 call signalling messages before initiating a call establishment procedure. The negotiation of security protocol does not incl
32、ude negotiation of particular security parameters/algorithms used by the security protocol as this is outside the scope of this Recommendation. Security parameters/algorithms could be configured or negotiated out-of-band, or be part of the handshake of the security protocol. ITU-T Rec. H.460.22 (01/
33、2007) 3 6.1 Call establishment security There are at least two reasons to secure a call establishment channel (i.e., H.225.0 call signalling channel). First, it is a simple way to authenticate the endpoints before accepting the call. Second, if call authorization is desired, then a secure mode of co
34、mmunication should be negotiated (such as TLS IETF RFC 4346 or IPsec IETF RFC 4302, IETF RFC 4303 for H.323) before the exchange of call establishment messages between endpoints. Alternatively, the authorization may also be provided based upon a service-specific authentication. The constraints of a
35、service-specific authorization policy are not considered in this Recommendation. 6.2 Negotiation of security mechanism The generic extensible framework (GEF) feature negotiation mechanism is used during the RAS communication. Whether or not this security negotiation mechanism is supported is negotia
36、ted between the endpoint and the gatekeeper. If neither the gatekeeper nor the endpoint supports this mechanism and no other security mechanism is used, the normal H.323 procedure will be followed. During the negotiation procedure, RAS messages can be protected by the password-based, digital signatu
37、re authentication and integrity methods or by other appropriate methods. The security negotiation procedure shall consist of the following steps: 1) The endpoint registers to the gatekeeper. The endpoint shall include the securityProtocolNegotiation feature in the supportedFeatures field in the feat
38、ureSet structure in the RRQ message. The parameters associated with the feature indicate all the supported H.225.0 call channel security protocols. Every protocol is assigned a preference value where a smaller number signifies a higher preference. 2) The gatekeeper returns an RCF or RRJ. The gatekee
39、per should indicate whether the negotiation mechanism is supported or not in the RCF. If this feature is supported, the gatekeeper shall include the securityProtocolNegotiation feature in the supportedFeatures field in the featureSet structure. The absence of securityProtocolNegotiation means the ga
40、tekeeper does not support this feature. There are no parameters present in the securityProtocolNegotiation feature in the RCF message. 3) The endpoint initiates a call. The endpoint shall send an ARQ before SETUP by including a list of all H.225.0 call channel security protocols that are supported.
41、4) The next step is determined based on whether the call is routed by the gatekeeper or not: a) If direct call model is used, the gatekeeper shall provide all of the H.225.0 call channel security protocols supported by the called endpoint in an ACF. b) If the gatekeeper-routed call model is used, th
42、e gatekeeper shall provide all of the H.225.0 call channel security protocols that it supports. The gatekeeper may send an ARJ message according to security policy. 5) If the calling endpoint receives an ACF, it shall check the returned supported H.225.0 call channel security protocols in the ACF an
43、d choose a common H.225.0 call channel security protocol which the called endpoint most prefers to set up H.225.0 call signalling channel. Figure 6-1 shows a general call flow scenario. In this scenario, it is assumed that there are at least two endpoints which belong to the same gatekeeper. These e
44、ndpoints (e.g., endpoint A and endpoint B in Figure 6-1) may be H.323 terminals, MCUs, gateways etc., and are served by a single gatekeeper (named gatekeeper A). It is further assumed that H.323 endpoints communicate directly end-to-end for call establishment. 4 ITU-T Rec. H.460.22 (01/2007) Gatekee
45、per AEndpoint A Endpoint BRAS channel messageCall signalling channel message12345678910GRQGCFRRQRCFARQACFSet-upARQACFConnect123456 984123710Figure 6-1 Both endpoints are registered with the same gatekeeper Direct call signalling For the negotiation of a common security protocol list, the correspondi
46、ng message flows of Figure 6-1 are detailed as follows: 1) Endpoints A and B send a GRQ message that includes, in the supportedFeatures in the featureSet field of the GRQ, the securityProtocolNegotiation feature. This feature should include all the H.225.0 call signalling channel security protocols
47、they support. 2) The gatekeeper returns a GCF message that includes, in the supportedFeatures in the featureSet field of the GCF, the securityProtocolNegotiation feature. The feature negotiation procedure is optional at the GRQ/GCF stage. 3) Endpoints A and B send an RRQ that includes, in the suppor
48、tedFeatures in the featureSet field, the securityProtocolNegotiation feature. This feature should include all of the H.225.0 call signalling channel security protocols they support. 4) The gatekeeper returns an RCF message that includes, in the supportedFeatures of the featureSet field of the RCF, t
49、he securityProtocolNegotiation feature. The gatekeeper shall keep the endpoints supported security protocols for future use. 5) Before endpoint A initiates a call to endpoint B, endpoint A sends an ARQ message including the securityProtocolNegotiation feature with all the H.225.0 call signalling channel security protocols it supports to gatekeeper A. 6) Depending on the security policy and whether there is a common security protocol between endpoint A and endpoint B, gatekeeper A may return an ACF message including endpoint Bs securityProt
