Resumen

  • RFC 3329 hizo que un agente SIP y su primer salto intercambiaran capacidades, activaran el mecanismo común de mayor preferencia y devolvieran la lista estática completa del servidor como Security-Verify a través de la protección seleccionada.
  • La comparación detectaba la eliminación, pero no garantizaba seguridad moderna ni cifrado: su límite era el mecanismo permitido más débil que aún ofreciera integridad y defensa contra repetición.

La propuesta inicial carecía de la protección que debía elegir

Actualizar una red extensa exige convivencia. Algunos equipos solo entienden Digest; otros añaden TLS o IPsec. Configurar de antemano cada pareja elimina flexibilidad. Probar mecanismos hasta que uno funcione permite que un atacante falsifique un error y convierta una capacidad disponible en aparente incompatibilidad.

Negociar parece resolverlo: el cliente enumera sus opciones, el servidor ordena las suyas y ambos eligen la mejor coincidencia. Sin embargo, esas listas iniciales circulan antes de encender la opción elegida. Un atacante situado en el camino podía borrar TLS, dejar Digest y lograr que dos equipos capaces de cifrar aceptaran una protección inferior sin ver un fallo.

RFC 3329 separó oferta y prueba. El cliente enviaba Security-Client a la siguiente entidad SIP. El servidor respondía con Security-Server, una lista estática ordenada por preferencias, más los datos necesarios para iniciar una opción. El cliente elegía el mecanismo conocido con mayor preferencia común, lo activaba y enviaba otro pedido con Security-Verify, réplica de la lista del servidor. El servidor comparaba el recibo con su política.

La igualdad incluía mecanismos, orden y parámetros. Si la respuesta original contenía cuatro opciones y el atacante había quitado la primera, el cliente devolvía tres. El servidor todavía conocía sus cuatro y rechazaba la solicitud. Ocultar la diferencia exigía alterar también el segundo pedido, ahora protegido por el mecanismo seleccionado.

Así cambió el costo. En el primer mensaje bastaba una supresión. En el segundo, el atacante debía falsificar en tiempo real la integridad de una asociación activa. La oferta inicial no se volvió segura de manera retroactiva; su manipulación dejó una contradicción verificable.

Una lista independiente evitaba que la mentira cerrara sobre sí misma

La lista del servidor no podía depender de Security-Client. Si el servidor filtrara lo que el cliente no anunció, el atacante podría reducir primero la lista cliente, provocar una respuesta igualmente reducida y obtener un recibo coherente. La política del servidor debía ser estática en su ámbito. Un nodo podía tener listas distintas por interfaz, pero cada una existía antes de observar la oferta.

El diseño también evitó nuevo estado SIP en el servidor. No hacía falta recordar un desafío singular por cliente: al volver la solicitud protegida, Security-Verify se cotejaba con la configuración. TLS o IPsec podían mantener su propio estado, pero la prueba de lista no añadía otra sesión.

Las preferencias q debían ser distintas. El cliente seleccionaba la opción conocida con el valor más alto de la lista servidor. Alterar Security-Client podía impedir que el servidor enviara material de inicio o llevar a elecciones divergentes. La comunicación fallaría y señalaría un ataque posible, aunque también podía ser una avería o una configuración obsoleta.

El alcance era el agente y su siguiente salto. Un servidor que iniciaba el acuerdo comprobaba una sola entrada Via; varias significaban que ya no era la primera entidad. Por ello, el acuerdo no era seguridad SIP de extremo a extremo ni protegía automáticamente cada proxy o el cuerpo del mensaje.

421 y 494 eran decisiones, no acusaciones

En el flujo iniciado por el cliente, la solicitud no protegida llevaba Security-Client y sec-agree en Require y Proxy-Require. El servidor devolvía 494 Security Agreement Required con su lista, incluso sin coincidencia común.

La política del servidor también podía exigir el procedimiento. Un cliente que no anunciaba la extensión recibía 421 Extension Required. Si ya declaraba soporte, pero todavía no había acordado la protección, recibía 494. Ambas respuestas incluían capacidades e información para iniciar el mecanismo preferido.

Un 421 no demostraba ataque: podía ser un cliente antiguo. Un 494 podía ser el primer turno normal, una discrepancia o la recuperación tras caducidad. Para interpretar el evento había que conservar listas, código, material de inicio, selección, resultado de protección y comparación.

Cada opción empezaba de forma distinta. TLS abría una conexión protegida y reutilizaba las reglas de localización SIP. Digest incorporaba la lista del servidor a su verificación. IPsec-IKE intentaba establecer IKE, mientras IPsec manual dependía de claves y política externas. RFC 3310 añadía AKA al entorno Digest, pero no sustituía la devolución de la lista.

También variaba el final. El cierre de TLS exigía renegociar. IKE fijaba duración. Digest podía volver a desafiar cuando las credenciales dejaban de valer. IPsec manual heredaba reglas externas. Un registro completo necesitaba identificar la asociación y su terminación.

La opción heredada fijaba la resistencia real

La condición más incómoda estaba en la sección de seguridad: la opción propuesta más débil debía ofrecer integridad y protección contra repetición para Security-Verify. Si un atacante podía romperla, la negociación no la fortalecía. La compatibilidad definía el suelo de seguridad.

El éxito tampoco equivalía a confidencialidad. Digest podía autenticar sin ocultar el contenido SIP. TLS protegía un salto. IPsec dependía de la asociación y selectores aplicados. La igualdad del recibo demostraba continuidad de una lista en un punto, no secreto global ni garantía moderna.

RFC 3329 apareció en enero de 2003. RFC 8996 lo actualizó al prohibir TLS 1.0 y 1.1. RFC 8446 define TLS 1.3 y RFC 7616 revisa Digest. La arquitectura de recibo persiste; el significado de una opción segura envejece.

Los errata muestran otra frontera. Dos ejemplos incluyen Security-Verify en ACK, aunque la tabla normativa lo marca como no aplicable; la corrección espera una revisión documental. Un erratum verificado corrige la longitud SPI de ipsec-3gpp. IANA registra los nombres, pero esa existencia no prueba despliegue ni seguridad.

RFC 3329 dejó una idea reutilizable: cuando la protección llega después de la negociación, transportar la oferta original hasta un canal protegido y devolverla permite descubrir alteraciones. El recibo confirma continuidad. La política que decidió aceptar la opción más débil sigue necesitando su propia defensa.

Fuentes