5 May
2008
5 May
'08
5:32 p.m.
El Lunes, 5 de Mayo de 2008, Victor Pascual Ávila escribió:
Retomando el thread,
¿Cómo puede un UA verificar que el From del Invite que recibe es
realmente de quien dice ser?
En teoría el UA (UAS destino) debe "fiarse" de su proxy del cuál recibe ese
INVITE. Y se supone que el proxy se ha encargado de autenticar al usuario, o
tal vez el INVITE venga a su vez de otro proxy que tiene relación de
confianza con nuestro proxy, etc etc...
2008/4/2 Jesus Rodriguez <jesusr(a)voztele.com>om>:
El PPI lo pone un UAC solicitando a su proxy qué PAI poner. O sea, en teoría
un UAC no puede enviar un PAI a su proxy puesto que, en teoría, un proxy
nunca ve a un UAC como "trusted" (pero sí al contrario). De hecho si un proxy
recibe un PAI de un elemento no considerado como "trusted" debe ignorarlo (y
eliminarlo) o rechazar el mensaje directamente.
También creo recordar de cuando me leí el RFC sobre PAI/PPI, que un UAC puede
poner un PPI para indicar al proxy quién es (y cómo autenticarse) a la vez
que solicita a su proxy que el INVITE salga como "anónimo". Por ejemplo
Twinkle implementa este comportamiento si marcas la casilla "Llamada anónima"
y genera un INVITE así:
---------
INVITE sip:pepe@dominio.com SIP/2.0
Max-Forwards: 70
To: <sip:pepe@dominio.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=fqtlx
Contact: <sip:192.168.0.129;transport=udp>
Privacy: id
P-Preferred-Identity: "IBC" <sip:ibc@aliax.net>
----------
Fíjate que el From no indica un URI sobre el que el proxy podría exigir
autenticación, pero para evitar sea rechazado se supone que el proxy debería
mirar el PPI y exigir autenticación para ese PPI (ibc(a)aliax.net).
Además, como valor añadido, Twinkle "esconde" el username en el
"Contact" y
añade el "Privacy: id".
Así pues, el proxy debería exigir autenticación para el usuario ibc(a)aliax.net.
Tras recibirla, y suponiendo que el proxy envía el INVITE a otro nodo trusted
de su red (por ejemplo un gateway o lo que sea), el proxy generaría un INVITE
así:
---------
INVITE sip:pepe@dominio.com SIP/2.0
Max-Forwards: 70
To: <sip:pepe@dominio.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=fqtlx
Contact: <sip:192.168.0.129;transport=udp>
Privacy: id
P-Asserted-Identity: "IBC" <sip:ibc@aliax.net>
----------
Ya no hay PPI sino PAI, que es lo que tiene sentido entre nodos trusted. Y se
mantiene el "Privacy: id".
El siguiente proxy/gateway/cosa_sip envía finalmente el INVITE a un elemento
no trusted (un UAS registrado en él por ejemplo) que tendría esta pinta:
---------
INVITE sip:pepe@dominio.com SIP/2.0
Max-Forwards: 70
To: <sip:pepe@dominio.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=fqtlx
Contact: <sip:192.168.0.129;transport=udp>
----------
Es decir, el destino finalmente no se entera de quién llama.
PD: No sé para qué me esfuerzo en entender esto si luego no lo usa ni cristo
XDDD
--
Iñaki Baz Castillo
Por desgracia, como siempre pasa, los
fabricantes implementan lo que
les rota y el P-Preferred-Identity todavía no está muy extendido y
casi todo el mundo tira de RPID/PAI.
¿Qué diferencias hay entre el PPI y el RPID/PAI?