> >>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.
In such a situation, the authentication service will still be able to validate the signature. This may be sufficient until or unless replay attacks are causing havoc. If It Ss Considered that replay attacks are a small problem, then that's all you need to do and breaking the media plane is fine. However, as attackers get more sophisticated and capable of replay attacks, it will be necessary to use DTLS/TLS/HIP/ICE proof of possession of the private key. One could also implement a system where edge SBCs perform the DTLS/TLS/HIP/ICE validation on behalf of the endpoints; this might be suitable for certain network (such as endpoints that cannot or will not support DTLS/TLS/HIP/ICE themselves but who need strong identity for phone calls for whitelists, blacklists, and useful reptuation systems). -d > 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
