1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T H.460.22 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (04/2015) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services Supplementary services for multimedia Negotiation of security protocols
2、to protect ITU-T H.225.0 call signalling messages Recommendation ITU-T 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 synchroniza
3、tion H.220H.229 Systems aspects H.230H.239 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 Qu
4、ality of service architecture for audiovisual and multimedia services H.360H.369 Telepresence H.420H.429 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-Seri
5、es multimedia systems and services H.510H.519 Mobile multimedia 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.
6、559 Mobile multimedia collaboration inter-working procedures H.560H.569 BROADBAND, TRIPLE-PLAY AND ADVANCED MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 Advanced multimedia services and applications H.620H.629 Ubiquitous sensor network applications and Internet of Things H.
7、640H.649 IPTV MULTIMEDIA SERVICES AND APPLICATIONS FOR IPTV General aspects H.700H.719 IPTV terminal devices H.720H.729 IPTV middleware H.730H.739 IPTV application event handling H.740H.749 IPTV metadata H.750H.759 IPTV multimedia application frameworks H.760H.769 IPTV service discovery up to consum
8、ption H.770H.779 Digital Signage H.780H.789 E-HEALTH MULTIMEDIA SERVICES AND APPLICATIONS Interoperability compliance testing of personal health systems (HRN, PAN, LAN, TAN and WAN) H.820H.859 Multimedia e-health data exchange services H.860H.869 For further details, please refer to the list of ITU-
9、T Recommendations. Rec. ITU-T H.460.22 (04/2015) i Recommendation ITU-T H.460.22 Negotiation of security protocols to protect ITU-T H.225.0 call signalling messages Summary Recommendation ITU-T H.460.22 defines a security negotiation mechanism for ITU-T H.225.0 call signalling. The negotiated securi
10、ty mechanism between two entities is to be applied for ITU-T H.225.0 call signalling messages before initiating a call establishment procedure. Detailed negotiation procedures, which provide the necessary security interoperability among ITU-T H.323 systems, are specified in this Recommendation. The
11、syntax of the security capability parameters in call signalling messages is also specified. This revision includes procedural clarifications and introduces support for ITU-T H.460.18 and ITU-T H.460.19 NAT traversal and negotiating datagram transport layer security (DTLS) for ITU-T H.323 Annex E ove
12、r UDP transport. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T H.460.22 2007-01-13 16 11.1002/1000/9041 1.1 ITU-T H.460.22 (2007) Cor. 1 2008-06-13 16 11.1002/1000/9489 2.0 ITU-T H.460.22 2015-04-29 16 11.1002/1000/12456 _ * To access the Recommendation, type the URL http:
13、/handle.itu.int/ in the address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T H.460.22 (04/2015) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the fie
14、ld of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) 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 standardiz
15、ing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, 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
16、 by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate
17、 both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved w
18、hen all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPE
19、RTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted
20、 by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that
21、 this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2015 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec.
22、ITU-T H.460.22 (04/2015) iii Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 2 4 Abbreviations and acronyms 2 5 Conventions 2 6 Negotiation description . 2 6.1 Call establishment security . 3 6.2 Negotiation of security mechanism 3 7 Feature description securityProtocolNegotiation
23、. 7 7.1 tlsSecurityProtocol . 7 7.2 ipsecSecurityProtocol . 8 7.3 dtlsSecurityProtocol . 8 8 NAT traversal considerations . 9 Rec. ITU-T H.460.22 (04/2015) 1 Recommendation ITU-T H.460.22 Negotiation of security protocols to protect ITU-T H.225.0 call signalling messages 1 Scope This Recommendation
24、specifies the security negotiation mechanism for ITU-T H.225.0 call signalling message exchanges. The main goals include the following. 1) Secure selection of the security mechanism. Otherwise, the procedure of negotiation is vulnerable to certain attacks such as malicious manipulation or bidding-do
25、wn attacks. The entire registration, admission and status (RAS) message shall be protected during the negotiation procedure. 2) Involved ITU-T H.323 entities shall determine mutually agreed security protocols without requiring additional round trips. 3) Entities involved in the negotiation procedure
26、 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 reference in this text,
27、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 recent edition of t
28、he 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 Recommendation ITU-T H.2
29、25.0 (2009), Call signalling protocols and media stream packetization for packet-based multimedia communication systems. ITU-T H.235.6 Recommendation ITU-T H.235.6 (2014), H.323 security: Encryption profile with native ITU-T H.235/H.245 key management. ITU-T H.235.8 Recommendation ITU-T H.235.8 (200
30、5), H.323 security: Key exchange for SRTP using secure signalling channels. ITU-T H.323 Recommendation ITU-T H.323 (2009), Packet-based multimedia communications systems. ITU-T H.460.1 Recommendation ITU-T H.460.1 (2002), Guidelines for the use of the generic extensible framework. ITU-T H.460.17 Rec
31、ommendation ITU-T H.460.17 (2005), Using H.225.0 call signalling connection as transport for H.323 RAS messages. ITU-T H.460.18 Recommendation ITU-T H.460.18 (2013), Traversal of ITU-T H.323 signalling across network address translators and firewalls. IETF RFC 5246 IETF RFC 5246 (2008), The Transpor
32、t Layer Security (TLS) Protocol Version 1.2. IETF RFC 6347 IETF RFC 6347 (2012), Datagram Transport Layer Security Version 1.2. 2 Rec. ITU-T H.460.22 (04/2015) 3 Definitions This Recommendation does not define any terms. 4 Abbreviations and acronyms This Recommendation uses the following abbreviatio
33、ns and acronyms: ACF Admission Confirmation ARJ Admission Reject ARQ Admission Request DTLS Datagram Transport Layer Security FW Firewall GCF Gatekeeper Confirmation GEF Generic Extensible Framework GRQ Gatekeeper Request IPSec Internet Protocol Security LCF Location Confirmation LRJ Location Reject
34、 LRQ Location Request MCU Multipoint Control Unit MiTM Man in The Middle NAT Network Address Translator RAS Registration, Admission and Status RCF Registration Confirmation RRJ Registration Reject RRQ Registration Request SCI Service Control Indication TCP Transmission Control Protocol TLS Transport
35、 Layer Security 5 Conventions In this Recommendation, the following 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 Ne
36、gotiation description The protection of ITU-T H.225.0 call signalling messages is important for the security of ITU-T H.323 systems. In small networks, network administrators can ensure that all ITU-T H.323 entities use the same security protocol. However, in large networks, such as where endpoints
37、are distributed in different network domains, a calling endpoint may not know in advance the security Rec. ITU-T H.460.22 (04/2015) 3 protocol supported by the called endpoint. Therefore, it is necessary for the two endpoints to negotiate the security mechanism for ITU-T H.225.0 call signalling mess
38、ages before initiating a call establishment procedure. The negotiation of actual security parameters/algorithms is outside the scope of this Recommendation. 6.1 Call establishment security There are a number of important reasons to secure the call signalling channel (i.e., ITU-T H.225.0). When using
39、 ITU-T H.235.6 or ITU-T H.235.8 to encrypt the media packets, the keys are exchanged in the signalling channel. These keys are sent either in the clear and require a secure signalling channel or are susceptible to man in the middle (MiTM) attacks and should be protected by a secure call signalling c
40、hannel. It also provides a very simple way to authenticate the endpoints to each other in direct call signalling mode or for each hop of the call in gatekeeper routed mode. 6.2 Negotiation of security mechanism The generic extensible framework (GEF) feature negotiation mechanism ITU-T H.460.1 is use
41、d during the RAS communication. Whether or not this security negotiation mechanism is supported is negotiated 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 ITU-T H.323 procedure will be
42、followed. The security negotiation procedure shall consist of the following steps. 1) The endpoint, where enabled, discovers the gatekeeper. The endpoint shall advertise the securityProtocolNegotiation feature as a supportedFeature in the featureSet field of the gatekeeper request (GRQ). All paramet
43、ers of the securityProtocolNegotiation feature shall be omitted. Where the gatekeeper supports this feature, it shall advertise as a supportedFeature with all parameters omitted in the reply GRQ. The absence of securityProtocolNegotiation feature indicates the gatekeeper does not support this featur
44、e. 2) Where the endpoint has discovered support for this feature or is registering without discovery, the endpoint shall include the securityProtocolNegotiation feature as a supportedFeature in the featureSet field in the registration request (RRQ) message. The parameters associated with the feature
45、 shall indicate all the security protocols supported by the endpoint. Every protocol is assigned a preference value, where a smaller number signifies a higher preference. The gatekeeper stores this information for call establishment purposes. Lightweight RRQs shall only include the securityProtocolN
46、egotiation feature advertisement and omit all parameters. 3) The gatekeeper returns a registration confirmation (RCF) or registration reject (RRJ). The gatekeeper shall indicate whether the negotiation mechanism is supported in the RCF. If this feature is supported, the gatekeeper shall include the
47、securityProtocolNegotiation feature as a supportedFeature in the featureSet field. The absence of securityProtocolNegotiation shall indicate that the gatekeeper does not support this feature. There are no parameters present in the securityProtocolNegotiation feature in the RCF message. 4) The endpoi
48、nt initiates a call. The endpoint shall send an ARQ to the gatekeeper including a securityProtocolNegotiation feature as a supportedFeature in the featureSet field of the admission request (ARQ). All parameters shall be omitted. 5) The next step is determined based on whether the call is routed by t
49、he gatekeeper. a) If direct call model is used, the gatekeeper shall send an ARQ containing the highest priority matching security protocol supported by both endpoints and shall include the stored connnectionAddress of the called endpoint where applicable. The priority field shall be omitted. 4 Rec. ITU-T H.460.22 (04/2015) b) If the gatekeeper-routed call model is used, the gatekeeper shall send an ARQ containing the highest priority matching security protocols that the calling endpoint and gatekee
