ImageVerifierCode 换一换
格式:PDF , 页数:24 ,大小:376.42KB ,
资源ID:797448      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-797448.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(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)为本站会员(吴艺期)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

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

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1