1、 International Telecommunication Union ITU-T H.235.7TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (09/2005) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Systems aspects H.323 security: Usage of the MIKEY key management protocol for the Secure Real Time Transpo
2、rt Protocol (SRTP) within H.235 ITU-T Recommendation H.235.7 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 Sys
3、tems 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 Quality of service ar
4、chitecture for audiovisual 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.5
5、19 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.559Mobile multimedia collaboration inter-wo
6、rking procedures H.560H.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.235.7 (09/2005) i ITU-T Recommendation H.235.7 H.323 security: Usage of the MIKEY key mana
7、gement protocol for the Secure Real Time Transport Protocol (SRTP) within H.235 Summary The purpose of this Recommendation is to describe security procedures for H.323/H.235-based systems for using the MIKEY key management protocol in conjunction with the Secure Real Time Transport Protocol. In earl
8、ier versions of the H.235 sub-series, this profile was contained in Annex G/H.235. Appendices IV, V, VI to H.235.0 show the complete clause, figure, and table mapping between H.235 versions 3 and 4. Source ITU-T Recommendation H.235.7 was approved on 13 September 2005 by ITU-T Study Group 16 (2005-2
9、008) under the ITU-T Recommendation A.8 procedure. Keywords Media encryption, MIKEY key management, multimedia security, secure Real Time Transport Protocol, security profile, SRTP. ii ITU-T Rec. H.235.7 (09/2005) FOREWORD The International Telecommunication Union (ITU) is the United Nations special
10、ized agency in the field of telecommunications. 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 standardizing telecommunications on a w
11、orldwide 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 by the procedure laid down i
12、n 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 both a telecommunication adm
13、inistration 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 when all of these mandatory prov
14、isions 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 PROPERTY RIGHTS ITU draws attention
15、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 by ITU members or others outs
16、ide 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, implementors are cautioned that this may not represent the la
17、test information and are therefore strongly urged to consult the TSB patent database. ITU 2006 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.235.7 (09/2005) iii CONTENTS Page 1 Scope 1 2 Referenc
18、es. 1 2.1 Normative references 1 2.2 Informative references and Bibliography. 2 3 Definitions 2 4 Symbols and abbreviations. 2 5 Conventions 3 6 Introduction 4 7 Overview and scenarios 5 7.1 MIKEY operation at “session level“ 6 7.2 MIKEY operation at “media level“ 7 7.3 MIKEY capability negotiation
19、. 8 8 Security profile using symmetric security techniques 9 8.1 Terminating a H.323 call 14 8.2 TGK re-keying and CSB updating . 15 8.3 H.245 tunnelling support 16 8.4 SRTP algorithms 16 8.5 List of object identifiers 17 9 Security profile using asymmetric security techniques 17 9.1 Terminating a H
20、.323 call 21 9.2 TGK re-keying and CSB updating . 21 9.3 H.245 tunnelling support 23 9.4 SRTP algorithms 23 9.5 List of object identifiers 23 Appendix I MIKEY-DHHMAC option 23 I.1 Terminating a H.323 call 27 I.2 TGK re-keying and CSB updating . 28 Appendix II Using H.235.4 for establishing a pre-sha
21、red secret 30 II.1 Terminating a H.323 call 32 II.2 TGK re-keying and CSB updating . 32 iv ITU-T Rec. H.235.7 (09/2005) Introduction The purpose of this Recommendation is to provide recommendations of security procedures for H.323/H.235-based systems to use the IETF MIKEY key management protocol in
22、conjunction with the IETF SRTP security protocol. This Recommendation is written as a security profile of ITU-T Rec. H.235 that is offered as an option and may complement the other media security features of ITU-T Rec. H.235.6. This Recommendation enables the deployment of SRTP media security where
23、the MIKEY key management supplies the necessary keys and security parameters among the involved endpoints end-to-end. This Recommendation can be deployed within a H.323 domain among H.235.7-enabled H.323 systems. This Recommendation defines the security protocol extensions to H.225.0 RAS and Call Si
24、gnalling as well as H.245, along with the corresponding procedures. Furthermore, this Recommendation provides the capabilities to support interworking with IETF SIP entities that have implemented the MIKEY key management and SRTP. ITU-T Rec. H.235.7 (09/2005) 1 ITU-T Recommendation H.235.7 H.323 sec
25、urity: Usage of the MIKEY key management protocol for the Secure Real Time Transport Protocol (SRTP) within H.235 1 Scope The purpose of this Recommendation is to provide recommendations of security procedures for H.323/H.235-based systems to use the MIKEY key management protocol in conjunction with
26、 the SRTP security protocol. This security profile is offered as an option and may complement the other media security features of H.235.6. 2 References 2.1 Normative references The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constit
27、ute 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 the Reco
28、mmendations 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 Recommendation H.225.0 (2003), Call sig
29、nalling protocols and media stream packetization for packet-based multimedia communication systems. 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 Recommendation H.235.1 (2005), H.323 security: Baseline
30、 security profile. ITU-T Recommendation H.235.3 (2005), H.323 security: Hybrid security profile. ITU-T Recommendation H.235.4 (2005), H.323 security: Direct and selective routed call security. ITU-T Recommendation H.245 (2005), Control protocol for multimedia communication. ITU-T Recommendation H.32
31、3 (2003), Packet-based multimedia communication systems. ITU-T Recommendation X.800 (1991), Security Architecture for Open Systems Interconnection for CCITT applications. ISO/IEC 10118-3:2004, Information Technology Security techniques Hash functions Part 3: Dedicated hash functions. IETF RFC 3550 (
32、2003), RTP: A Transport Protocol for Real-Time Applications. IETF RFC 3711 (2004), The Secure Real Time Transport Protocol (SRTP). IETF RFC 3830 (2004), MIKEY: Multimedia Internet KEYing. 2 ITU-T Rec. H.235.7 (09/2005) 2.2 Informative references and Bibliography IETF RFC 1305 (1992), Network Time Pr
33、otocol (Version 3) Specification, Implementation and Analysis. IETF RFC 2327 (1999), SDP: Session description protocol. IETF RFC 2631 (1999), Diffie-Hellman Key Agreement Method. IETF RFC 3261 (2002), SIP: Session Initiation Protocol. IETF RFC 3264 (2002), An Offer/Answer Model with the Session Desc
34、ription Protocol (SDP). IETF RFC ssss (2005), M. Handley, Van Jacobson, C. Perkins: SDP: Session Description Protocol, draft-ietf-mmusic-sdp-new-24.txt. IETF RFC wwww (2005), J. Arkko, E. Carrara et al: Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol
35、 (RTSP), Internet Draft draft-ietf-mmusic-kmgmt-ext-14.txt, Work in Progress. IETF RFC zzzz (2005), M. Euchner: HMAC-authenticated Diffie-Hellman for MIKEY, Internet Draft draft-ietf-msec-MIKEY-DHHMAC-11.txt, Work in Progress. 3 Definitions None. 4 Symbols and abbreviations This Recommendation uses
36、the following abbreviations: a, b, e, d private DH key of EP A, EP B, GK E, GK D Cert digital certificate (see RFC 3830) CP/C CallProceeding-to-Connect CSB Crypto Session Bundle (see RFC 3830) CTB, CTAClearToken for endpoint B, ClearToken for endpoint A (see H.235.4) DRC1 Direct-routed Call (see H.2
37、35.4) ENCk(x) Encryption of X using key k env_key Envelope key (RFC 3830) between endpoint B and endpoint A EP Endpoint ESC H.245 EndSessionCommand DH Diffie-Hellman DHADH half-key of endpoint A DHBDH half-key of endpoint B ga, gbDiffie-Hellman half-key of EP A, EP B ge, gdDiffie-Hellman half-key of
38、 GK E, GK D GK Gatekeeper HDR MIKEY header payload (see RFC 3830) IDA, IDBIdentity (i.e., endpoint ID) of endpoint A, Identity of endpoint B ITU-T Rec. H.235.7 (09/2005) 3 IETF Internet Engineering Task Force Imsg MIKEY message of the initiator (see RFC 3830) KEMAC MIKEY KEMAC payload message (see R
39、FC 3830) MAC(k, x) Keyed MAC on x using key k Ma MIKEY authentication key (see RFC 3830) Me MIKEY encryption key (see RFC 3830) MIKEY Multimedia Internet Keying NTP Network Time Protocol PKE MIKEY PKE payload message (see RFC 3830) PKI Public-Key Infrastructure PRF Pseudo-Random Function (MIKEY-PRF,
40、 see RFC 3830 sections 4.1.2-4.1.4) Rand random nonce (see RFC 3830) Rmsg MIKEY message of the responder (see RFC 3830) rand() random value RSA Rivest, Shamir and Adleman (public key algorithm) sa, sb shared secret among endpoint A and GK, shared secret among endpoint B and GK sl shared secret among
41、 gatekeepers SDP Session Description Protocol SHA1 Secure Hash Algorithm 1 (ISO/IEC 10118-3) SIP Session Initiation Protocol SP Security Policy (see RFC 3830) SRTCP Secure Real-time Transport Control Protocol SRTP Secure Real-time Transport Protocol (see RFC 3711) SSRC Synchronization source (RTP) T
42、 Timestamp (see RFC 3830) TGK Traffic Generating Key (see RFC 3830) between endpoint A and endpoint B V Verification message field (see RFC 3830) ZZABdynamic shared H.323 secret ZZAB Zero, one or more occurrences Optional element 5 Conventions The object identifiers are referenced through a symbolic
43、 reference in the text (e.g., “G1“), clauses 8.5 and 9.5 list the actual numeric values for the symbolic object identifiers, for further information see also clause 5/H.235.0. Table 1 defines the five MIKEY key management protocols that are being referenced throughout this Recommendation: 4 ITU-T Re
44、c. H.235.7 (09/2005) Table 1/H.235.7 MIKEY key management protocols MIKEY protocol Description OID value Parameter identifier Implementation MIKEY Any MIKEY protocol itu-t (0) recommendation (0) h (8) 235 version (0) 3 76 76 Mandatory toimplement MIKEY-PS Symmetric key distribution protocol using pr
45、e-shared symmetric keys and HMACs, (see RFC 3830). itu-t (0) recommendation (0) h (8) 235 version (0) 3 72 72 Mandatory toimplement MIKEY-DHHMAC Diffie-Hellman key agreement protocol using pre-shared symmetric keys and HMACs; (see RFC zzzz). itu-t (0) recommendation (0) h (8) 235 version (0) 3 73 73
46、 Optional MIKEY-PK-SIGN (RSA-based) public-key distribution protocol using digital signatures; (see RFC 3830). itu-t (0) recommendation (0) h (8) 235 version (0) 3 74 74 Mandatory toimplement. MIKEY-DH-SIGN Diffie-Hellman key agreement protocol using digital signatures; (see RFC 3830). itu-t (0) rec
47、ommendation (0) h (8) 235 version (0) 3 75 75 Optional MIKEY (cf. 1st row of Table 1) refers to the MIKEY protocol family generally without indicating specifically any particular MIKEY key management protocol variant such as MIKEY-PS, MIKEY-DHHMAC, MIKEY-PK-SIGN or MIKEY-DH-SIGN. The related impleme
48、ntation of MIKEY shall encompass processing of the MIKEY messages such as MIKEY common header payload (RFC 3830 section 6.1), but does not necessarily require any implementation of a particular MIKEY key management protocol or implementation of a particular MIKEY information payload. The correspondi
49、ng OID and parameter identifier shall be used in those cases where an H.323 endpoint does not know the actually used MIKEY protocol variant. In any other cases, it is recommended to use the specific OID and parameter identifier of the actual MIKEY key management protocol variant instead. 6 Introduction There has been interest in using the security features of IETF SRTP “Secure Real-time Protocol“ from ITU-T Rec. H.235. While former versions of H.235 already offer various media security features such as v
