Resumen

  • P-Preferred-Identity era una sugerencia para escoger entre identidades válidas del usuario autenticado; el proxy debía retirarla de cada mensaje reenviado.
  • La P-Asserted-Identity aportada por un elemento no confiable debía eliminarse o sustituirse por una construida tras autenticar al originador.

La elección no podía hacerse pasar por resultado

SIP ya tenía From, pero el usuario podía usarlo para presentar el alias deseado. Las redes que imitaban servicios telefónicos necesitaban otra identidad para entrega del llamante, trazabilidad y funciones internas, aun cuando el destinatario no debiera verla. RFC 3325 no hizo From más autoritativo. Creó una cadena donde cada campo respondía a un actor diferente.

From seguía siendo presentación. P-Preferred-Identity era una preferencia enviada por el agente solo a un proxy de confianza. Si el usuario autenticado disponía de varias identidades válidas, señalaba cuál deseaba que la red afirmara. P-Asserted-Identity era la afirmación que el proxy generaba después de autenticar o aceptaba de un par confiable. Preferir, verificar y afirmar eran verbos distintos.

Al recibir la preferencia de una entidad no confiada, el proxy podía considerarla una pista. Debía comprobarla contra el conjunto de identidades válidas del sujeto autenticado. Si no correspondía a ninguna, podía construir otra identidad o rechazar la solicitud. El usuario no podía ampliar su conjunto válido escribiendo un valor nuevo.

Después el proxy debía retirar toda P-Preferred-Identity proporcionada por el usuario antes de reenviar. La regla eliminaba ambigüedad de procedencia. Los sistemas posteriores verían el resultado del proxy, no el material de entrada. Si ambos viajaran juntos, una base de datos podría contar la sugerencia como corroboración independiente de la afirmación, aunque ambas procedieran de una sola elección.

La autoridad falsa debía desaparecer en la entrada

Una P-Asserted-Identity recibida desde un elemento no confiable exigía saneamiento más fuerte. Si el proxy quería insertar una afirmación, primero debía autenticar al originador y usar la identidad resultante. Escribir el nombre correcto de la cabecera no otorgaba derecho a afirmar.

Si la entrada ya contenía un URI SIP o SIPS afirmado, el proxy debía reemplazarlo por un único URI SIP o SIPS propio o eliminar la cabecera. Un URI telefónico seguía la misma regla. No bastaba conservar la cadena y marcar el mensaje como confiable. La autoridad anterior tenía que ser destruida o reconstruida con evidencia controlada por el proxy.

Cuando la afirmación provenía de un nodo confiado, el proxy podía utilizarla como si hubiera autenticado al usuario. La posibilidad dependía del modelo de RFC 3324: recepción segura, membresía configurada y Spec(T) describiendo autenticación, protección, privacidad y conformidad. No era certificación criptográfica de extremo a extremo.

RFC 3325 reconocía el límite. Las identidades no estaban certificadas criptográficamente y no identificaban al afirmante concreto; se atribuían al dominio. En una arquitectura que no satisficiera los requisitos, podían falsificarse, repetirse o alterarse. El mecanismo no ofrecía un modelo general de identidad para Internet, ni convertía la identidad en autorización o personalidad jurídica.

La salida podía requerir otra destrucción

Una vez generada la afirmación, cada proxy debía decidir si confiaba en el siguiente elemento. Hacia un nodo confiado conservaba valores propios o de fuente confiada. Hacia uno no confiado tenía que examinar Privacy.

El token id obligaba a retirar todas las P-Asserted-Identity antes de reenviar. none obligaba a no retirarlas. Sin Privacy, la política de Spec(T) decidía. El RFC recomendaba conservar la identidad para no romper servicios, pero advertía que hacerlo podía revelar información no solicitada y no evitable si los usuarios no tenían acceso a servicios de privacidad.

La sintaxis admitía uno o dos valores: con dos, uno SIP/SIPS y otro telefónico. La privacidad debía retirar todos. Eliminar solo uno dejaría escapar otra representación del mismo sujeto.

El servidor de usuario también recibía una orden clara. Si el elemento anterior no era confiado, no podía usar P-Asserted-Identity de ninguna forma. Dentro del dominio apropiado, la implementación decidía cómo mostrarla; la especificación no resolvía el significado de varias identidades para cada servicio.

RFC 5876 actualizó posteriormente el mecanismo. RFC 4474, RFC 8224 y RFC 8225 siguieron otros diseños de identidad autenticada y PASSporT, mientras RFC 4916 abordó identidad conectada. Esa evolución no cambia la enseñanza: una cabecera privilegiada obtiene autoridad por el proceso que la recrea y por los datos que el proceso destruye.

RFC 3325 convirtió la higiene de evidencia en comportamiento de protocolo. La preferencia podía guiar la decisión, pero debía dejar de existir antes de que el resultado circulara como afirmación de red.

Fuentes