1、 Unin Internacional de TelecomunicacionesUIT-T H.235.5SECTOR DE NORMALIZACIN DE LAS TELECOMUNICACIONES DE LA UIT (09/2005) SERIE H: SISTEMAS AUDIOVISUALES Y MULTIMEDIOS Infraestructura de los servicios audiovisuales Aspectos de los sistemas Marco de seguridad H.323: Marco para la autenticacin segura
2、 en RAS utilizando secretos compartidos dbiles Recomendacin UIT-T H.235.5 RECOMENDACIONES UIT-T DE LA SERIE H SISTEMAS AUDIOVISUALES Y MULTIMEDIOS CARACTERSTICAS DE LOS SISTEMAS VIDEOTELEFNICOS H.100H.199 INFRAESTRUCTURA DE LOS SERVICIOS AUDIOVISUALES Generalidades H.200H.219 Multiplexacin y sincron
3、izacin en transmisin H.220H.229 Aspectos de los sistemas H.230H.239 Procedimientos de comunicacin H.240H.259 Codificacin de imgenes vdeo en movimiento H.260H.279 Aspectos relacionados con los sistemas H.280H.299 Sistemas y equipos terminales para los servicios audiovisuales H.300H.349 Arquitectura d
4、e servicios de directorio para servicios audiovisuales y multimedios H.350H.359 Arquitectura de la calidad de servicio para servicios audiovisuales y multimedios H.360H.369 Servicios suplementarios para multimedios H.450H.499 PROCEDIMIENTOS DE MOVILIDAD Y DE COLABORACIN Visin de conjunto de la movil
5、idad y de la colaboracin, definiciones, protocolos y procedimientos H.500H.509 Movilidad para los sistemas y servicios multimedios de la serie H H.510H.519 Aplicaciones y servicios de colaboracin en mviles multimedios H.520H.529 Seguridad para los sistemas y servicios mviles multimedios H.530H.539 S
6、eguridad para las aplicaciones y los servicios de colaboracin en mviles multimedios H.540H.549 Procedimientos de interfuncionamiento de la movilidad H.550H.559 Procedimientos de interfuncionamiento de colaboracin en mviles multimedios H.560H.569 SERVICIOS DE BANDA ANCHA Y DE TRADA MULTIMEDIOS Servic
7、ios multimedios de banda ancha sobre VDSL H.610H.619 Para ms informacin, vase la Lista de Recomendaciones del UIT-T. Rec. UIT-T H.235.5 (09/2005) i Recomendacin UIT-T H.235.5 Marco de seguridad H.323: Marco para la autenticacin segura en RAS utilizando secretos compartidos dbiles Resumen Esta Recome
8、ndacin proporciona el marco para la autenticacin mutua de las partes durante intercambios RAS H.255.0. Los mtodos “prueba-de-posesin“ aqu descritos permiten proteger el uso de secretos compartidos tales como contraseas que, si se utilizaran solas, no proporcionaran seguridad suficiente. Se describen
9、 tambin extensiones al marco para permitir la negociacin simultnea de parmetros de seguridad de la capa de transporte para la proteccin de un canal conexo de sealizacin de llamada. En las versiones anteriores de la subserie H.235, este perfil figuraba en el anexo H de la Recomendacin H.235. En los a
10、pndices IV, V y VI a la H.235.0 figuran las tablas de correspondencia de clusulas, figuras y cuadros entre las versiones 3 y 4. Orgenes La Recomendacin UIT-T H.235.5 fue aprobada el 13 de septiembre de 2005 por la Comisin de Estudio 16 (2005-2008) del UIT-T por el procedimiento de la Recomendacin UI
11、T-T A.8. Palabras clave Autenticacin, contrasea, seguridad. ii Rec. UIT-T H.235.5 (09/2005) PREFACIO La UIT (Unin Internacional de Telecomunicaciones) es el organismo especializado de las Naciones Unidas en el campo de las telecomunicaciones. El UIT-T (Sector de Normalizacin de las Telecomunicacione
12、s de la UIT) es un rgano permanente de la UIT. Este rgano estudia los aspectos tcnicos, de explotacin y tarifarios y publica Recomendaciones sobre los mismos, con miras a la normalizacin de las telecomunica-ciones en el plano mundial. La Asamblea Mundial de Normalizacin de las Telecomunicaciones (AM
13、NT), que se celebra cada cuatro aos, establece los temas que han de estudiar las Comisiones de Estudio del UIT-T, que a su vez producen Recomendaciones sobre dichos temas. La aprobacin de Recomendaciones por los Miembros del UIT-T es el objeto del procedimiento establecido en la Resolucin 1 de la AM
14、NT. En ciertos sectores de la tecnologa de la informacin que corresponden a la esfera de competencia del UIT-T, se preparan las normas necesarias en colaboracin con la ISO y la CEI. NOTA En esta Recomendacin, la expresin “Administracin“ se utiliza para designar, en forma abreviada, tanto una adminis
15、tracin de telecomunicaciones como una empresa de explotacin reconocida de telecomunicaciones. La observancia de esta Recomendacin es voluntaria. Ahora bien, la Recomendacin puede contener ciertas disposiciones obligatorias (para asegurar, por ejemplo, la aplicabilidad o la interoperabilidad), por lo
16、 que la observancia se consigue con el cumplimiento exacto y puntual de todas las disposiciones obligatorias. La obligatoriedad de un elemento preceptivo o requisito se expresa mediante las frases “tener que, haber de, hay que + infinitivo“ o el verbo principal en tiempo futuro simple de mandato, en
17、 modo afirmativo o negativo. El hecho de que se utilice esta formulacin no entraa que la observancia se imponga a ninguna de las partes. PROPIEDAD INTELECTUAL La UIT seala a la atencin la posibilidad de que la utilizacin o aplicacin de la presente Recomendacin suponga el empleo de un derecho de prop
18、iedad intelectual reivindicado. La UIT no adopta ninguna posicin en cuanto a la demostracin, validez o aplicabilidad de los derechos de propiedad intelectual reivindicados, ya sea por los miembros de la UIT o por terceros ajenos al proceso de elaboracin de Recomendaciones. En la fecha de aprobacin d
19、e la presente Recomendacin, la UIT ha recibido notificacin de propiedad intelectual, protegida por patente, que puede ser necesaria para aplicar esta Recomendacin. Sin embargo, debe sealarse a los usuarios que puede que esta informacin no se encuentre totalmente actualizada al respecto, por lo que s
20、e les insta encarecidamente a consultar la base de datos sobre patentes de la TSB. UIT 2006 Reservados todos los derechos. Ninguna parte de esta publicacin puede reproducirse por ningn procedimiento sin previa autorizacin escrita por parte de la UIT. Rec. UIT-T H.235.5 (09/2005) iii NDICE Pgina 1 Al
21、cance . 1 2 Referencias . 1 2.1 Referencias normativas 1 2.2 Referencias informativas 1 3 Definiciones 2 4 Abreviaturas, siglas o acrnimos 2 5 Convenios . 3 6 Marco bsico. 3 6.1 Capacidades de negociacin mejoradas en H.235.0. 3 6.2 Utilizacin entre punto extremo y controlador de acceso 3 6.3 Utiliza
22、cin de perfiles entre controladores de acceso 6 6.4 Criptacin y autenticacin de canales de sealizacin. 7 7 Perfil de seguridad especfico (SP1). 7 8 Perfil de seguridad mejorado (SP2) 9 8.1 Nmero de secuencia de sealizacin de llamada 9 8.2 Generacin de claves de criptacin dbiles a partir de contrasea
23、s. 10 8.3 Tamao de Nonce. 10 8.4 Adicin de un vector de inicializacin . 10 8.5 Codificacin del ClearToken 10 9 Extensiones al marco (informativo) 11 9.1 Utilizacin de la clave maestra para proteger el canal de sealizacin de llamada mediante TLS 11 9.2 Utilizacin de certificados para autenticar el co
24、ntrolador de acceso . 13 9.3 Utilizacin de otros mecanismos de seguridad de la sealizacin. 13 10 Amenazas (informativo) . 13 10.1 Ataque pasivo . 13 10.2 Ataques por denegacin de servicio. 13 10.3 Ataques de intromisin ataques MIM (man-in-the-middle) 14 10.4 Ataques por intentos de adivinar 14 10.5
25、Media clave del controlador de acceso no criptada 14 iv Rec. UIT-T H.235.5 (09/2005) Introduccin En muchas aplicaciones, un punto extremo (o su usuario) y su controlador de acceso pueden compartir solamente un “pequeo“ secreto como una contrasea o un nmero de identificacin personal (PIN). Ese secret
26、o (que en adelante se designar por “contrasea“), y toda clave de criptacin derivada del mismo, es criptogrficamente dbil. Los esquemas de autenticacin descritos en la clusula 10 son ejemplos de texto explcito y el correspondiente texto cifrado de la solicitacin y la respuesta, que estn expuestas a a
27、taques exhaustivos de parte de un observador de la transaccin cuando las autenticaciones se introducen por contraseas simples. Por tanto, el observador puede recuperar la contrasea y o PIN y despus hacerse pasar como el punto extremo para obtener el servicio. Hay varios protocolos del tipo de interc
28、ambio de clave criptada, que utilizan un secreto compartido para “oscurecer“ un intercambio con clave Diffie-Hellman de tal manera que el atacante tenga que resolver una serie de problemas de logaritmo finito para validar un ataque exhaustivo contra el secreto compartido. En el intercambio de clave
29、criptada (EKE, encrypted key exchange) de Bellovin y Merritt B para facilitar el anlisis, a cada uno de estos elementos se le dar un nombre, en vez de un valor identificador. 6.2 Utilizacin entre punto extremo y controlador de acceso No plantea problemas el marco bsico, en el cual el solicitante es
30、un punto extremo que desea inscribirse ante un controlador de acceso, y el respondedor es ese controlador de acceso. En adelante se supone implcitamente que cada ClearToken mencionado se identifica con el tokenOID del perfil de identificacin. Se supone que el ClearToken est extendido. Los elementos
31、random y/o random2 pueden ser utilizados por un perfil de una de estas dos maneras: pueden ser incluidos en el clculo de la clave de autenticacin, y/o pueden incluirse en un ClearToken de perfil en cada mensaje RAS subsiguiente (por ejemplo, RRQ/RCF) para evitar ataques por reproduccin. El intercamb
32、io de registro de punto extremo se efecta como sigue: 1) El punto extremo anuncia su intencin de participar en uno o ms esquemas de negociacin y autenticacin de claves incluyendo el (los) ID de objeto apropiados para el perfil o perfiles deseados en elementos authenticationMechanism.keyExch del elem
33、ento authenticationCapability de la GatekeeperReQuest. Se supone que cada OID especfico define completamente un procedimiento de autenticacin en trminos de un sistema de claves pblicas (por ejemplo, Diffie-Hellman o curva elptica) y un grupo especfico (por ejemplo, uno de los grupos OAKLEY de RFC 24
34、12), algoritmo de criptacin simtrico (por ejemplo, AES-128-CBC con robo de texto cifrado), funcin de derivacin de clave (por 4 Rec. UIT-T H.235.5 (09/2005) ejemplo, mediante la funcin seudoaleatoria de la clusula 10/H.235.0), cdigo de autenticacin de mensajes (por ejemplo, HMAC-SHA1-96 RFC 2104), y
35、la secuencia en que se utilizan. El punto extremo incluye tambin uno o ms ClearToken de perfil en la GRQ, cada uno de los cuales transporta el OID para el perfil especfico ofrecido y el material de clave pblica (criptado) en la forma siguiente: a) tokenOID transporta el perfil OID como se ofrece en
36、la authenticationCapability de la GRQ encapsulante. b) timeStamp puede utilizarse para asegurar que la transaccin est en curso y proteger contra los ataques por reproduccin. c) password no se utilizar para la contrasea efectiva. d) dhkey transporta los parmetros de clave Diffie-Hellman, si se utiliz
37、an. El elemento halfkey encerrado se cripta como se especifica por el perfil seleccionado. e) challenge no se requiere. f) random lo suministra la parte iniciadora y se utiliza para prevenir ataques por reproduccin. g) certificate puede utilizarse si el intercambio de certificados forma parte del pe
38、rfil. h) generalID puede utilizarse si lo requiere el perfil. i) eckasdhkey transporta los parmetros de clave por curva elptica, si los utiliza el perfil. El elemento public-key encerrado debe criptarse como se especifica por el perfil. j) sendersID puede especificarse conforme al perfil. k) Es posi
39、ble proporcionar el elemento profileInfo, initVect junto con el material de clave pblica (criptado) (dhkey o eckasdhkey) si el perfil requiere un vector de inicializacin para descriptacin. l) Si el iniciador desea utilizar material de clave derivado de un intercambio anterior, incluir un elemento pr
40、ofileInfo, designado por sessionID, que contiene el identificador asignado durante el intercambio anterior. En este caso, dhkey, eckasdhkey y/o initVect no deben incluirse. m) Si el iniciador desea establecer una sesin TLS para una conexin de sealizacin de llamada, puede incluir uno o ms elementos p
41、rofileInfo que contienen sucesiones cifradas TLS; el mensaje contendr un solo conjunto de cifrado (la negociada previamente) si sessionID est presente. n) Si el iniciador desea establecer una sesin TLS para sealizacin de llamada, puede incluir un elemento profileInfo que contiene una lista de mtodos
42、 de compresin; slo un mtodo de compresin (el negociado previamente) deber incluirse si sessionID est presente. o) Pueden utilizarse ms elementos profileInfo para todo parmetro adicional requerido por los procedimientos en el perfil. 2) Al recibir la GRQ, el controlador de acceso selecciona un perfil
43、 AuthenticationMechanism de la lista ofrecida, genera una clave privada adecuada, calcula la clave pblica correspondiente, genera un vector de inicializacin si se necesita para criptacin simtrica utilizando la contrasea, cripta la clave pblica, genera un ID de sesin nico, y genera un nmero aleatorio
44、, todo lo cual se codifica en un ClearToken. En funcin del perfil, los elementos del ClearToken se utilizan como sigue: a) tokenOID transporta el OID de perfil correspondiente al authenticationMethod de la GCF encapsulante. b) timeStamp puede utilizarse para asegurarse que la transaccin est en curso
45、 y proteger contra ataques por reproduccin. Rec. UIT-T H.235.5 (09/2005) 5 c) password no se utilizar para la contrasea real. d) dhkey transporta los parmetros Diffie-Hellman, si se utilizan. El elemento halfkey incluido se cripta como se especifica segn el perfil seleccionado. e) challenge se utili
46、za para transportar un vector de inicializacin, si se requiere para criptacin de clave como se especifica por el perfil, o puede utilizarse para transportar una cadena aleatoria que habr de ser devuelta por el punto extremo para prevenir ataques por reproduccin. f) random puede contener el valor nic
47、o, impredecible, suministrado por el solicitante para prevenir ataques por reproduccin. g) certificate puede utilizarse si el intercambio de certificados forma parte del perfil. h) generalID puede utilizarse si lo requiere el perfil. i) eckasdhkey transporta los parmetros de curva elptica, si los ut
48、iliza el perfil. El elemento public-key incluido debe criptarse como se especifica segn el perfil. j) sendersID puede utilizarse como se especifica segn el perfil. k) random (o un elemento profileInfo adicional, designado por random2, si el perfil requiere que ambos nmeros permanezcan en el intercam
49、bio de mensajes) debe contener un valor nico, impredecible, suministrado por el respondedor para proteger contra ataques por reproduccin. l) initVect se suministra junto con el material de clave pblica (criptada) (dhkey o eckasdhkey) si el perfil requiere un vector de inicializacin para descriptacin. m) sessionID es un identifi
