[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] SIP Identity using Media Path
Hi,
>>Chapter 9 says:
>>
>>"in order for the mechanism to work, SBC-type-of-entities must permit
>>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path."
>>
>>A small question for clarification: at what point must this exchange
>>(two-way, I assume) work? As soon as the UAS has received the INVITE?
>
>Yes.
As we know from our RTPSEC discussions, one of the issues of using
SBC-type-of-entities (or gates) is that you MAY NOT have end-to-end
media plane connectivity as soon as the INVITE has been sent.
Regards,
Christer
>The DTLS, TLS, ICE, or HIP exchange would need to occur prior
>to displaying Caller-ID-like information to the user --
>otherwise, an attacker could spoof that Caller-ID
>information. It seems defective, to me, to display Caller-ID
>information that was spoofed to only later learn (after doing
>DTLS, TLS, ICE, or HIP) that the calling party had lied about
>their identity.
>
>There is some protection against such an attack that could
>reduce this risk (the Date: header is signed, so the attacker
>would need to obtain a relatively recent SIP request) -- that
>protection might be sufficient in networks that block
>exchange of packets prior to 200 Ok. If an attacker was able
>to get ahold of such a SIP request, you would know it when
>the attacker failed the DTLS, TLS, ICE, or HIP exchange,
>which I suppose is better than nothing.
>
> -d
>