> > The public key challange/response, described in > > draft-wing-sip-identity-media-02, provides better identity > > assurance than signing IP address and UDP port (as done by > > RFC4474). Obviously the media is still un-encrypted, though, > > and encrypted media is better than un-encrypted media. > > I don't understand this. If there is a media transcoder, > then what does this identity assurance mean??? The media > is not protected. Am I missing something?
RFC4474 doesn't protect the media, either, yet it provides identity. Let's pull the two different attacks apart. There is a difference between them: One attack has someone spoof a "From:", and causes the victim to have a bona-fide conversation with the attacker spoofing the "From:". Protection from that attack is achieved with either RFC4474 (and no SDP modifications between the RFC4474 'authentication service' and 'verifier'), or with the ICE public-key challange described in draft-wing-sip-identity-media. However, you are describing a different attack vector, where an attacker waits for a bona-fide phone call and then sends (and maybe can also also receive) RTP packets with the victim. The victim will believe those received RTP packets are legitimate. To protect from this attack you need to use SRTP. RFC4474 cannot provide protection from this attack unless we assume attackers cannot spoof the source IP address and port of their RTP packets to match the (signed) SDP. We know that attackers can spoof their source IP address. Similarly, the ICE public-key challange described in draft-wing-sip-identity-media does not protect from this attack vector. I look at this as part of a normal evolution of technology. Right now we are in the everybody-trusts-everyone-else camp where P-A-I and From are relatively trustable. This is how email was for about a decade, until that broke down. Then we will need something better for SIP to protect against spoofed From:, but something that is still easily deployed. I suggest that is something *like* the public-key challange described in draft-wing-sip-identity-media. Next, if attackers become more creative and deliver RTP to victims (e.g., "unsolicited advertising") we will need to use SRTP to protect against that sort of attack. > > > If we need transcoding, then we might want instead to have > > a security > > > mechanism with the transcoder instead. > > > > > > For example, we could use DTLS-SRTP where Alice is using > > the 4474-like > > > mechanism, but the transcoder is using it's own cert > (instead of a > > > self-signed one). That cert's credentials would already be > > provisioned > > > in Alice's device. That would seem like a simple way to do this. > > > > Ignoring SRTP for a moment, the complexities involved there > > are asounding. For example call forwarding and call > > transfers might need to invoke, or remove, a translator, in a > > far-removed service provider or enterprise (e.g., forwarding > > your work calls to your house). > > Well, no, not at all. > > The model there would be a model where you would HAVE to anchor the > media at the service provider (probably the first SBC). The encryption > would be between Alice and that. But if some service provider in the middle needs to drop the call to <some spiffy codec> which isn't supported by Alice's SP nor by Bob's SP -- what would that service provider do? Not deploy that spiffy new codec, even though it would save them thousands of dollars a day in satellite bandwidth fees? > PS: Don't get me wrong, I'm not saying I like this. I a firm > non-believer in all this transcoding stuff. I'd rather have the > end-to-end DTLS-SRTP instead. -d _______________________________________________ Sip mailing list https://www.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
