Strict Standards: Declaration of action_plugin_importoldchangelog::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/guz2/public_html/voip/lib/plugins/importoldchangelog/action.php on line 8

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parserutils.php on line 202

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parserutils.php on line 205

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parserutils.php on line 314

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parserutils.php on line 454

Strict Standards: Declaration of cache_instructions::retrieveCache() should be compatible with cache::retrieveCache($clean = true) in /home/guz2/public_html/voip/inc/cache.php on line 291

Deprecated: Function split() is deprecated in /home/guz2/public_html/voip/inc/auth.php on line 146

Warning: Cannot modify header information - headers already sent by (output started at /home/guz2/public_html/voip/lib/plugins/importoldchangelog/action.php:8) in /home/guz2/public_html/voip/inc/auth.php on line 236

Strict Standards: Only variables should be passed by reference in /home/guz2/public_html/voip/doku.php on line 69

Warning: Cannot modify header information - headers already sent by (output started at /home/guz2/public_html/voip/lib/plugins/importoldchangelog/action.php:8) in /home/guz2/public_html/voip/inc/actions.php on line 124
autentificacion_en_sip [Voip en Español]

Voip en Español

[[autentificacion_en_sip]]

Traza: » autentificacion_en_sip

Login

¡Actualmente no estás identificado! Introduce abajo tus datos de identificación para abrir una sesión. Necesitas tener las cookies activadas para identificarte.

Ingresar

Has olvidado tu contraseña? Obten una nueva.: Enviar nueva contraseña


Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/parser.php on line 66

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/lexer.php on line 292

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 22

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 44

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 208

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 236

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 290

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 323

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/handler.php on line 560

Deprecated: Assigning the return value of new by reference is deprecated in /home/guz2/public_html/voip/inc/parser/xhtml.php on line 980

Autentificación en SIP

ARREGLAR

El SIP proporciona un mecanismo apátrida, desafiar-basado para la autentificación que se basa en la autentificación en el HTTP. Cualquier momento eso un proxy server o un UA recibe una petición (con las excepciones dadas en la sección 22.1), PUEDE desafiar el iniciador de la petición de proporcionar aseguramiento de su identidad. Una vez que hayan identificado al autor, el recipiente de la petición DEBE comprobar si o autorizan a no este usuario a hacer la petición en la pregunta. No se recomienda ni se discute ningunos sistemas de la autorización en este documento.

El mecanismo de la autentificación del “resumen” descrito en esta sección proporciona la autentificación del mensaje y juega de nuevo la protección solamente, sin integridad del mensaje o secreto. Medidas protectoras sobre y más allá de ésos proporcionados por necesidad del resumen de ser tomado para evitar que los atacantes activos modifiquen peticiones y respuestas del SIP.

Observar que debido a su seguridad débil, el uso de la autentificación “básica” se ha desaprobado. Los servidores NO DEBEN aceptar las credenciales usando el esquema “básico” de la autorización, y los servidores también NO DEBEN desafiar con “básico”. Esto es un cambio de RFC 2543.

¿Cuál es un reino?

Generalmente, la autentificación del SIP es significativa para un reino específico, un dominio de protección. Así, para la autentificación del resumen, cada tal dominio de protección tiene su propio sistema de usernames y de contraseñas. Cotización de RFC2617:

REINO: Una secuencia que se exhibirán a los usuarios así que ellos saben qué username y contraseña a utilizar. Esta secuencia debe contener por lo menos el nombre del anfitrión que realiza la autentificación y pudo indicar además la colección de los usuarios que pudieron tener acceso. Un ejemplo pudo ser “registered_users@gotham.news.com”.

¿WWW o poder-auth?

  • Al authenticar al servidor que entregará un servicio, un jefe de la WWW-autentificación debe ser utilizado.
  • Al authenticar a un servidor que poder la petición a la punto final, la poder-autentificación debe ser utilizada.
  • En la transacción del _one_, el www_authentication y el proxy_authentication pueden ser utilizados

¿Falta de authenticar - 401 o 407? Si el servidor del origen no desea aceptar las credenciales enviadas con una petición, DEBE volver una respuesta (desautorizada) 401. La respuesta DEBE incluir un campo del jefe de la WWW-Autenticidad que contiene por lo menos un (posiblemente nuevo) desafío aplicable al recurso solicitado. Si un poder no acepta las credenciales enviadas con una petición, DEBE volver 407 (autentificación del poder requerida). La respuesta DEBE incluir un campo del jefe de la Poder-Autenticidad que contiene el desafío de a (posiblemente nueva) aplicable al poder para el recurso solicitado.

Autentificación para el ACK y la CANCELACIÓN

Bajo esquema de la autentificación que utiliza respuestas para llevar los valores computaban nonces (tales como resumen), algunos problemas suben para cualquier petición que no tome ninguna respuesta, incluyendo el ACK. Por esta razón, cualquier credencial en la INVITACIÓN que fuera aceptada por un servidor SE DEBE aceptar por ese servidor para el ACK. UACs que crea un mensaje del ACK duplicará los valores del campo de todo el jefe de la autorización y de la Poder-Autorización que aparecieron en la INVITACIÓN a la cual el ACK corresponde. Los servidores NO DEBEN procurar desafiar un ACK. Aunque el método de la CANCELACIÓN toma una respuesta (un 2xx), los servidores NO DEBEN procurar desafiar peticiones de la CANCELACIÓN puesto que estas peticiones no pueden ser resometidas. Generalmente, una petición de la CANCELACIÓN SE DEBE aceptar por un servidor si viene del mismo salto que envió la petición que era cancelada (a condición de que una cierta clase de asociación de la seguridad de la capa del transporte o de red, según lo descrito en la sección 26.2.1, está en lugar).

Así pues, resumir:

  • La autentificación del SIP se hace con un username de la autentificación y un reino de la autentificación.
  • El servidor desafía a usuario con un reino y un “nonce”
  • Si el usuario tiene un username dentro de este reino, calcula una respuesta basada en un número de datos, incluyendo un “secreto”
  • El username de la autentificación no tiene que ser igual que el nombre del usuario del SIP
  • El reino de la autentificación no tiene que ser igual que el dominio del SIP
  • Muchos agentes del usuario del SIP tienen puestas en práctica quebradas donde no puedes fijar el username de la autentificación y el reino
  • La mejor solución estaría para un agente del usuario para tener uno el fijar para el username del SIP y el dominio, y entonces un sistema de los ajustes para la autentificación a los varios reinos. ¿’’ Cómo lo hace el authententicate de I dentro de este reino? “.
  • Muchos clientes están limitados hoy para tener el mismo username/contraseña para todos los reinos, que no es una manera muy buena de manejar seguridad.

Autentificación del resumen del HTTP El esquema de la autentificación del resumen del HTTP se documenta en RFC2617 y se amplía en RFC 3310.

  • SIP | REGISTRO
 

Strict Standards: Only variables should be passed by reference in /home/guz2/public_html/voip/doku.php on line 77