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

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

1、 Union internationale des tlcommunicationsUIT-T H.235.5SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE LUIT (09/2005) SRIE H: SYSTMES AUDIOVISUELS ET MULTIMDIAS Infrastructure des services audiovisuels Aspects systme Cadre de scurit H.323: cadre de lauthentification scurise pendant lchange de me

2、ssages RAS au moyen de secrets partags faibles Recommandation UIT-T H.235.5 RECOMMANDATIONS UIT-T DE LA SRIE H SYSTMES AUDIOVISUELS ET MULTIMDIAS CARACTRISTIQUES DES SYSTMES VISIOPHONIQUES H.100H.199 INFRASTRUCTURE DES SERVICES AUDIOVISUELS Gnralits H.200H.219 Multiplexage et synchronisation en tran

3、smission H.220H.229 Aspects systme H.230H.239 Procdures de communication H.240H.259 Codage des images vido animes H.260H.279 Aspects lis aux systmes H.280H.299 Systmes et quipements terminaux pour les services audiovisuels H.300H.349 Architecture des services dannuaire pour les services audiovisuels

4、 et multimdias H.350H.359 Architecture de la qualit de service pour les services audiovisuels et multimdias H.360H.369 Services complmentaires en multimdia H.450H.499 PROCDURES DE MOBILIT ET DE COLLABORATION Aperu gnral de la mobilit et de la collaboration, dfinitions, protocoles et procdures H.500H

5、.509 Mobilit pour les systmes et services multimdias de la srie H H.510H.519 Applications et services de collaboration multimdia mobile H.520H.529 Scurit pour les systmes et services multimdias mobiles H.530H.539 Scurit pour les applications et services de collaboration multimdia mobile H.540H.549 P

6、rocdures dinterfonctionnement de la mobilit H.550H.559 Procdures dinterfonctionnement de collaboration multimdia mobile H.560H.569 SERVICES LARGE BANDE ET MULTIMDIAS TRI-SERVICES Services multimdias large bande sur VDSL H.610H.619 Pour plus de dtails, voir la Liste des Recommandations de lUIT-T. Rec

7、. UIT-T H.235.5 (09/2005) i Recommandation UIT-T H.235.5 Cadre de scurit H.323: cadre de lauthentification scurise pendant lchange de messages RAS au moyen de secrets partags faibles Rsum La prsente Recommandation dcrit le cadre de lauthentification mutuelle entre participants au cours de lchange de

8、 messages RAS H.225.0. Les mthodes fondes sur la “preuve de possession“ dcrites permettent une utilisation sre des secrets partags tels que les mots de passe qui, sils taient utiliss en tant que tels, ne garantiraient pas une scurit suffisante. Sont galement dcrites les extensions de ce cadre visant

9、 permettre la ngociation simultane des paramtres de scurit de la couche de transport pour la protection dun canal de signalisation dappel ultrieur. Dans les anciennes versions de la sous-srie H.235, ce profil tait dfini dans lAnnexe H/H.235. Les Appendices IV, V et VI/H.235.0 donnent le mappage entr

10、e tous les paragraphes, toutes les figures et tous les tableaux de la version 3 et tous ceux de la version 4 de la Rec. UIT-T H.235. Source La Recommandation UIT-T H.235.5 a t approuve le 13 septembre 2005 par la Commission dtudes 16 (2005-2008) de lUIT-T selon la procdure dfinie dans la Recommandat

11、ion UIT-T A.8. Mots cls Authentification, mots de passe, scurit. ii Rec. UIT-T H.235.5 (09/2005) AVANT-PROPOS LUIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications. LUIT-T (Secteur de la normalisation des tlcommunication

12、s) est un organe permanent de lUIT. Il est charg de ltude des questions techniques, dexploitation et de tarification, et met ce sujet des Recommandations en vue de la normalisation des tlcommunications lchelle mondiale. LAssemble mondiale de normalisation des tlcommunications (AMNT), qui se runit to

13、us les quatre ans, dtermine les thmes dtude traiter par les Commissions dtudes de lUIT-T, lesquelles laborent en retour des Recommandations sur ces thmes. Lapprobation des Recommandations par les Membres de lUIT-T seffectue selon la procdure dfinie dans la Rsolution 1 de lAMNT. Dans certains secteur

14、s des technologies de linformation qui correspondent la sphre de comptence de lUIT-T, les normes ncessaires se prparent en collaboration avec lISO et la CEI. NOTE Dans la prsente Recommandation, lexpression “Administration“ est utilise pour dsigner de faon abrge aussi bien une administration de tlco

15、mmunications quune exploitation reconnue. Le respect de cette Recommandation se fait titre volontaire. Cependant, il se peut que la Recommandation contienne certaines dispositions obligatoires (pour assurer, par exemple, linteroprabilit et lapplicabilit) et considre que la Recommandation est respect

16、e lorsque toutes ces dispositions sont observes. Le futur dobligation et les autres moyens dexpression de lobligation comme le verbe “devoir“ ainsi que leurs formes ngatives servent noncer des prescriptions. Lutilisation de ces formes ne signifie pas quil est obligatoire de respecter la Recommandati

17、on. DROITS DE PROPRIT INTELLECTUELLE LUIT attire lattention sur la possibilit que lapplication ou la mise en uvre de la prsente Recommandation puisse donner lieu lutilisation dun droit de proprit intellectuelle. LUIT ne prend pas position en ce qui concerne lexistence, la validit ou lapplicabilit de

18、s droits de proprit intellectuelle, quils soient revendiqus par un Membre de lUIT ou par une tierce partie trangre la procdure dlaboration des Recommandations. A la date dapprobation de la prsente Recommandation, lUIT avait t avise de lexistence dune proprit intellectuelle protge par des brevets acq

19、urir pour mettre en uvre la prsente Recommandation. Toutefois, comme il ne sagit peut-tre pas de renseignements les plus rcents, il est vivement recommand aux responsables de la mise en uvre de consulter la base de donnes des brevets du TSB. UIT 2006 Tous droits rservs. Aucune partie de cette public

20、ation ne peut tre reproduite, par quelque procd que ce soit, sans laccord crit pralable de lUIT. Rec. UIT-T H.235.5 (09/2005) iii TABLE DES MATIRES Page 1 Domaine dapplication 1 2 Rfrences. 1 2.1 Rfrences normatives 1 2.2 Rfrences informatives . 1 3 Termes et dfinitions 2 4 Abrviations 2 5 Conventio

21、ns 3 6 Cadre de base 3 6.1 Capacits de ngociation amliores dans la Rec. UIT-T H.235.0 3 6.2 Utilisation entre le point dextrmit et le portier. 3 6.3 Utilisation de profils entre portiers. 6 6.4 Chiffrement et authentification des canaux de signalisation 7 7 Profil de scurit spcifique (SP1) . 7 8 Pro

22、fil de scurit amlior (SP2) 9 8.1 Numro de squence des messages de signalisation dappel 10 8.2 Gnration dune cl de chiffrement faible partir du mot de passe 10 8.3 Taille de nonce . 11 8.4 Salage du vecteur dinitialisation 11 8.5 Codage du champ ClearToken . 11 9 Extensions du cadre ( titre indicatif

23、). 11 9.1 Utilisation de la cl matresse pour scuriser le canal de signalisation dappel via le protocole TLS. 11 9.2 Utilisation de certificats pour lauthentification du portier. 13 9.3 Utilisation dautres mcanismes de scurit de signalisation . 13 10 Menaces ( titre indicatif). 13 10.1 Attaques passi

24、ves 13 10.2 Attaques de type dni de service 14 10.3 Attaques par intercepteur 14 10.4 Prvoir les attaques. 14 10.5 Demi-cl non chiffre par le portier . 15 iv Rec. UIT-T H.235.5 (09/2005) Introduction Dans de nombreuses applications, un point dextrmit (ou son utilisateur) et son portier ne peuvent ch

25、anger quun “petit“ secret tel quun mot de passe ou un “numro didentification personnel“ (PIN, personal identification number). Ce type de secret (ci-aprs dnomm “mot de passe“) et toute cl de chiffrement calcule partir de celui-ci sont faibles dun point de vue cryptographique. Les mcanismes dauthenti

26、fication de type preuve/rponse, tels que dcrits dans le 10, prvoient des chantillons de textes en clair et de textes chiffrs correspondants, et sont par consquent exposs des attaques de type “force brute“ de la part dun observateur de la transaction en question lorsque les authentifications sont eff

27、ectues au moyen de simples mots de passe. Lobservateur peut ainsi rcuprer le mot de passe ou le numro PIN et se faire ensuite passer pour le point dextrmit afin dobtenir un service. Un ensemble de protocoles classs sous la rubrique gnrique de lchange de cls chiffres utilise un secret partag pour “oc

28、culter“ un change de cls Diffie-Hellman de telle faon que lattaquant doit rsoudre une srie de problmes de logarithme discret pour valider une attaque de type force brute par rapport au secret partag. Selon le protocole dchange de cls chiffres (EKE, encrypted key exchange) de Bellovin et Merritt B la

29、 forme “devrait/devraient“ indique une mesure suggre mais facultative; la forme “peut/peuvent“ indique une action possible plutt quune action recommande. Pour les autres conventions, on se reportera au 5/H.235.0. 6 Cadre de base 6.1 Capacits de ngociation amliores dans la Rec. UIT-T H.235.0 La Rec.

30、UIT-T H.235.0 permet de prendre en charge le prsent cadre de scurit grce linclusion de llment gnrique suivant dans le champ ClearToken: profileInfo est une squence dlments propres un profil donn, chaque lment tant identifi par sa propre valeur entire telle que dfinie par le profil dont lidentificate

31、ur dobjet (OID) est achemin dans llment ClearToken.tokenOID. Dans les descriptions qui suivent, plusieurs lments sont achemins dans la squence profileInfo. Pour faciliter la discussion, on donnera chacun de ces lments un nom plutt quune valeur identifiante. 6.2 Utilisation entre le point dextrmit et

32、 le portier Le cadre de base, dans lequel le demandeur est un point dextrmit souhaitant senregistrer auprs dun portier, et dans lequel le rpondant est ce portier, est simple. Dans ce qui suit, on part implicitement du principe que chaque champ ClearToken mentionn est identifi au moyen de llment toke

33、nOID du profil dauthentification. Le champ ClearToken est cens tre tendu. Les lments random et/ou random2 peuvent tre utiliss par un profil de deux faons diffrentes: ils peuvent tre inclus dans le calcul de la cl dauthentification et/ou dans un champ ClearToken de profil dans chaque message RAS ultr

34、ieur (par exemple, RRQ/RCF) afin dviter les rexcutions. Lchange pour lenregistrement dun point dextrmit se fait de la faon suivante: 1) le point dextrmit annonce son intention de participer un ou plusieurs mcanismes dauthentification ou de ngociation de cl en incluant le ou les identificateurs dobje

35、t appropris pour le ou les profils souhaits dans des lments authenticationMechanism.keyExch de llment authenticationCapability du message GatekeeperReQuest. On suppose que chaque identificateur OID spcifique dfinit entirement une procdure dauthentification en termes de systme cl publique (par 4 Rec.

36、 UIT-T H.235.5 (09/2005) exemple, Diffie-Hellman ou courbe elliptique) et de groupe concern (par exemple, un des groupes OAKLEY dcrits dans la norme RFC 2412), dalgorithme de chiffrement symtrique (par exemple, AES-128-CBC avec extraction cryptographique), de fonction de calcul de cl (par exemple, a

37、u moyen de la fonction pseudo-alatoire dcrite au 10/H.235.0), et de code dauthentification de message (par exemple, HMAC-SHA1-96 RCF2104) ainsi que la squence dans laquelle ils sont utiliss. Le point dextrmit inclut aussi un ou plusieurs champs ClearToken de profil dans le message GRQ, chacun achemi

38、nant lidentificateur OID pour le profil concern, ainsi que les donnes de cl publique (chiffres) ncessaires de la faon suivante: a) tokenOID achemine lidentificateur OID du profil, tel quil figure dans llment authenticationCapability du message GRQ encapsulant; b) timeStamp peut tre utilis pour garan

39、tir lactualit et viter les rexcutions; c) password ne doit pas tre utilis pour le mot de passe rel; d) dhkey achemine les paramtres de cl Diffie-Hellman, sil est utilis. Llment halfkey inclus est chiffr comme spcifi par le profil choisi; e) challenge nest pas requis; f) random est fourni par le dema

40、ndeur et est utilis pour viter les attaques par rexcution; g) certificate peut tre utilis si lchange de certificats fait partie du profil; h) generalID peut tre utilis sil est requis par le profil; i) eckasdhkey achemine les paramtres de cl de type courbe elliptique, sil est utilis dans le profil. L

41、lment public-key inclus devrait tre chiffr comme spcifi par le profil; j) sendersID peut tre utilis comme spcifi par le profil; k) un lment profileInfo, initVect, peut tre fourni avec les donnes (chiffres) de cl publique (dhkey ou eckasdhkey) si le profil exige un vecteur dinitialisation pour le dch

42、iffrement; l) sil souhaite utiliser des donnes de cl obtenues dun change antrieur, le demandeur doit inclure un lment profileInfo, appel sessionID, contenant lidentificateur attribu au cours de lchange antrieur. Dans ce cas, dhkey, eckasdhkey et/ou initVect ne devraient pas tre inclus; m) sil souhai

43、te tablir une session TLS pour une connexion de signalisation dappel, le demandeur peut inclure un ou plusieurs lments profileInfo contenant des suites cryptographiques TLS. Le message ne doit contenir quune suite cryptographique (celle ngocie pralablement) si llment sessionID est prsent; n) sil sou

44、haite tablir une session TLS pour la signalisation dappel, le demandeur peut inclure un lment profileInfo contenant une liste de mthodes de compression; une seule mthode de compression (celle ngocie pralablement) doit tre incluse si llment sessionID est prsent; o) dautres lments profileInfo peuvent

45、tre utiliss pour tout paramtre additionnel requis pour les procdures relevant du profil. 2) Lorsquil reoit le message GRQ, le portier choisit un profil AuthenticationMechanism parmi la liste propose, gnre une cl prive approprie, calcule la cl publique correspondante, gnre si ncessaire un vecteur din

46、itialisation pour le chiffrement symtrique au moyen du mot de passe, chiffre la cl publique, gnre un identificateur de session unique, et gnre enfin une quantit alatoire, tous ces lments tant cods dans un champ ClearToken. En fonction du profil, lutilisation des lments de ClearToken est la suivante:

47、 Rec. UIT-T H.235.5 (09/2005) 5 a) tokenOID achemine lidentificateur OID du profil, tel quil a t choisi partir de llment authenticationMethod du message GCF encapsulant; b) timeStamp peut tre utilis pour garantir lactualit et viter les rexcutions; c) password ne doit pas tre utilis pour le mot de passe rel; d) dhkey achemine les paramtres de cl Diffie-Hellman, sil est utilis. Llment halfkey inclus est chiffr comme spcifi par le profil choisi; e) challenge est utilis pour a