ITU-T H 235 5-2005 H 323 security Framework for secure authentication in RAS using weak shared secrets (Study Group 16)《H 323安全框架 在远程访问服务(RAS)中使用弱共享机密的安全认证框架 16号研究组》.pdf

《ITU-T H 235 5-2005 H 323 security Framework for secure authentication in RAS using weak shared secrets (Study Group 16)《H 323安全框架 在远程访问服务(RAS)中使用弱共享机密的安全认证框架 16号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 235 5-2005 H 323 security Framework for secure authentication in RAS using weak shared secrets (Study Group 16)《H 323安全框架 在远程访问服务(RAS)中使用弱共享机密的安全认证框架 16号研究组》.pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T H.235.5TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (09/2005) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Systems aspects H.323 security: Framework for secure authentication in RAS using weak shared secrets ITU-T

2、Recommendation H.235.5 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.239 Communication

3、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 audiovisual and multime

4、dia 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 collaboration app

5、lications 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.560H.569 BROADBAND

6、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.5 (09/2005) i ITU-T Recommendation H.235.5 H.323 security: Framework for secure authentication in RAS using weak shared secr

7、ets Summary This Recommendation provides the framework for mutual party authentication during H.225.0 RAS exchanges. The “proof-of-possession“ methods described permit secure use of shared secrets such as passwords which, if used by themselves, would not provide sufficient security. Extensions to th

8、e framework to permit simultaneous negotiation of Transport Layer Security parameters for protection of a subsequent call signalling channel are also described. In earlier versions of the H.235 sub-series, this profile was contained in H.235 Annex H. Appendices IV, V, VI to H.235.0 show the complete

9、 clause, figure, and table mapping between H.235 versions 3 and 4. Source ITU-T Recommendation H.235.5 was approved on 13 September 2005 by ITU-T Study Group 16 (2005-2008) under the ITU-T Recommendation A.8 procedure. Keywords Authentication, passwords, security. ii ITU-T Rec. H.235.5 (09/2005) FOR

10、EWORD The International Telecommunication Union (ITU) is the United Nations specialized 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 iss

11、uing Recommendations on them with a view to standardizing 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 to

12、pics. 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 necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expressio

13、n “Administration“ is used for conciseness to indicate 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)

14、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 equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recomme

15、ndation 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 claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of c

16、laimed 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 received notice of intellectual property, protected by patents, which may be required to implement this Recomme

17、ndation. However, implementors are cautioned that this may not represent the latest 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 permiss

18、ion of ITU. ITU-T Rec. H.235.5 (09/2005) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 1 3 Definitions 2 4 Abbreviations 2 5 Conventions 3 6 Basic framework. 3 6.1 Improved negotiation capabilities in H.235.0 3 6.2 Use between endpoint and gatekeep

19、er . 3 6.3 Use of profile between gatekeepers 6 6.4 Signalling channel encryption and authentication 6 7 A specific security profile (SP1). 6 8 An improved security profile (SP2) 8 8.1 Call Signalling sequence number . 9 8.2 Generation of Weak Encryption Key from password 9 8.3 Nonce size 9 8.4 Init

20、ialization vector salting. 9 8.5 ClearToken encoding 10 9 Extensions to the framework (Informative) 10 9.1 Using the master key to secure the call signalling channel via TLS 10 9.2 Use of certificates to authenticate the gatekeeper 12 9.3 Use of alternative signalling security mechanisms 12 10 Threa

21、ts (Informative) 12 10.1 Passive attack 12 10.2 Denial-of-Service attacks . 12 10.3 Man-in-the-Middle attacks . 13 10.4 Guessing attacks . 13 10.5 Unencrypted gatekeeper half-key. 13 iv ITU-T Rec. H.235.5 (09/2005) Introduction In many applications, an endpoint (or its user) and its gatekeeper may s

22、hare only a “small“ secret such as a password or a “personal identification number“ (PIN). Such a secret (which we shall hereafter refer to as a “password“), and any encryption key derived from it, is cryptographically weak. The challenge/response authentication schemes, as described in clause 10, p

23、rovide samples of plaintext and corresponding ciphertext and are, therefore, subject to a brute-force attack by an observer of the transaction when the authentications are keyed by simple passwords. Thus, the observer may recover the password or PIN and later pose as the endpoint to obtain service.

24、A family of protocols under the generic heading of Encrypted Key Exchange use a shared secret to “obscure“ a Diffie-Hellman key exchange in such a way that the attacker must solve a series of finite logarithm problems in order to validate a brute-force attack against the shared secret. In the Encryp

25、ted Key Exchange (EKE) of Bellovin and Merritt B users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly publish

26、ed. 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 signalling protocols and media stream packetization for packet-based multimedia communication systems. ITU-T Recommendation

27、 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 security profile. ITU-T Recommendation H.245 (2005), Control protocol for multimedia communication. ITU-T Recommendation

28、 H.323 (2003), Packet-based multimedia communications systems. Federal Information Processing Standard FIPS PUB 180-2, Secure Hash Standard, U.S. Department of Commerce, Technology Administration, National Institute of Standards and Technology, 1 August 2002. NIST Special Publication 800-38A 2001, R

29、ecommendation for Block Cipher Modes of Operation Methods and Techniques. http:/www.csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 2.2 Informative references AES IETF RFC 3268 (2002), Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security. B each of these elements w

30、ill be given a name, rather than an identifying value, for ease of discussion. 6.2 Use between endpoint and gatekeeper The basic framework, in which the requestor is an endpoint wishing to register with a gatekeeper, and the responder is that gatekeeper, proceeds in a straightforward manner. In the

31、following, it is implicitly assumed that each ClearToken mentioned is identified with the tokenOID of the authentication profile. The ClearToken is assumed to be extended. The random and/or random2 elements may be used by a profile in either of two ways: they may be included in the computation of th

32、e authentication key, and/or they may be included in a profile ClearToken in each subsequent RAS message (e.g., RRQ/RCF) to prevent replay. The endpoint registration exchange proceeds as follows: 1) The endpoint announces its willingness to participate in one or more key negotiation and authenticati

33、on schemes by including the appropriate object ID(s) for the desired profile(s) in authenticationMechanism.keyExch elements of the authenticationCapability element of the GatekeeperReQuest. It is assumed that each specific OID completely defines an authentication procedure in terms of public key sys

34、tem (e.g., Diffie-Hellman or Elliptic Curve) and specific group (e.g., one of the OAKLEY groups from RFC 2412), symmetric encryption algorithm (e.g., AES-128-CBC with ciphertext stealing), key derivation function (e.g., via the Pseudo-Random Function of clause 10/H.235.0), message authentication cod

35、e (e.g., HMAC-SHA1-96 RFC2104), and the sequence in which they are used. The endpoint also includes one or more profile ClearTokens in the GRQ, each of which carries the OID for the specific profile offered and the necessary (encrypted) public key material in the following form: a) tokenOID carries

36、the profile OID as offered in the authenticationCapability of the encapsulating GRQ. b) timeStamp may be used to assure currency and protect against replay. 4 ITU-T Rec. H.235.5 (09/2005) c) password shall not be used for the actual password. d) dhkey carries the Diffie-Hellman key parameters, if us

37、ed. The enclosed halfkey element is encrypted as specified by the selected profile. e) challenge is not required. f) random is supplied by the initiating party and is used to prevent replay attacks. g) certificate may be used if certificate exchange is part of the profile. h) generalID may be used i

38、f required by the profile. i) eckasdhkey carries the Elliptic Curve key parameters, if used by the profile. The enclosed public-key element should be encrypted as specified by the profile. j) sendersID may be used as specified by the profile. k) profileInfo element, initVect, may be supplied along w

39、ith the (encrypted) public key material (dhkey or eckasdhkey) if the profile requires an initialization vector for decryption. l) If the initiator wishes to use key material derived from an earlier exchange, it shall include a profileInfo element, denoted sessionID, containing the identifier assigne

40、d during the earlier exchange. In this case, dhkey, eckasdhkey and/or initVect should not be included. m) If the initiator wishes to establish a TLS session for a call signalling connection, it may include one or more profileInfo elements containing TLS ciphersuites; the message shall contain only o

41、ne ciphersuite (the one previously negotiated) if sessionID is present. n) If the initiator wishes to establish a TLS session for call signalling, it may include a profileInfo element containing a list of compression methods; only one compression method (the one previously negotiated) shall be inclu

42、ded if sessionID is present. o) More profileInfo elements may be used for any additional parameters required for the procedures under the profile. 2) Upon receiving the GRQ, the gatekeeper selects an AuthenticationMechanism profile from the offered list, generates a suitable private key, computes th

43、e corresponding public key, generates an initialization vector if needed for symmetric encryption using the password, encrypts the public key, generates a unique session ID, and generates a random quantity, all of which are encoded into a ClearToken. Depending on the profile, the following use is ma

44、de of the ClearToken elements: a) tokenOID carries the profile OID, as selected from the authenticationMethod of the encapsulating GCF. b) timeStamp may be used to assure currency and protect against replay. c) password shall not be used for the actual password. d) dhkey carries the Diffie-Hellman k

45、ey parameters, if used. The enclosed halfkey element is encrypted as specified by the selected profile. e) challenge is used to carry an initialization vector, if required for key encryption as specified by the profile, or it may be used to carry a random string to be returned by the endpoint to pre

46、vent replay attacks. f) random may contain the unpredictable, unique value supplied by the requestor to prevent replay attacks. g) certificate may be used if certificate exchange is part of the profile. h) generalID may be used if required by the profile. ITU-T Rec. H.235.5 (09/2005) 5 i) eckasdhkey

47、 carries the Elliptic Curve key parameters, if used by the profile. The enclosed public-key element should be encrypted as specified by the profile. j) sendersID may be used as specified by the profile. k) random (or an additional profileInfo element, denoted random2, if the profile requires both ra

48、ndom numbers to remain in the message exchange) should contain an unpredictable, unique value supplied by the responder to protect against replay attacks. l) initVect is supplied along with the (encrypted) public key material (dhkey or eckasdhkey) if the profile requires an initialization vector for

49、 decryption. m) sessionID is a unique (to the gatekeeper) identifier used to identify this registration session. Under certain profiles, it may also be used as a TLS session ID for rapid establishment of a TLS-protected call signalling channel. n) profileInfo may be used for any additional parameters required for the procedures under the profile. The gatekeeper then computes the shared secret or master key using its private key and the (decrypted) public key from the GCF, and derives from the master key the necessary encryption keys, authenticati