RE: [Sip] SIP Identity using Media Path

["Dan Wing" <dwing@xxxxxxxxx>]

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:christer.holmberg@xxxxxxxxxxxx] 
> Sent: Thursday, July 19, 2007 3:11 AM
> To: Dan Wing; sip@xxxxxxxx
> Cc: ietf-rtpsec@xxxxxxx
> Subject: RE: [Sip] SIP Identity using Media Path
> 
> 
> Hi, 
> 
> >>"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.
> 
> A little more on this.
> 
> As we have discussed before, you may not have two-way connectivity
> before 200 OK.
>
> I am pretty sure what will not work with most SBCs.
>
> Now assume that you will have two-way connectivity before you 
> have even sent the SDP answer. 


I think you meant to say "now assume that you will _not_ ..."?


In the case of no media path, it would only be possible for the
authentication server, and the UA receiving the SIP request, to 
cryptographically validate the SIP headers and a very minor 
portion of the SDP (From:, Date:, and the header that we 
generate that copies the a=fingerprint attributes from the 
SDP, and the few other headers described in 
-wing-sip-identity-media).

This provides some protection against attackers, and works through
SBCs.  Specifically, this protects against attackers who were not
able to obtain a validly-signed SIP request.


However, only validating those SIP headers is inadequate if
an attacker has captured or otherwise acquired a validly-signed 
SIP request, modified the SDP (such that the signature is 
still valid), and re-injected that SIP request into a SIP 
proxy that forwards it to you.  In order to detect such a 
replay attack, you need to perform one of the media-path based 
tests that I describe in wing-sip-identity-media (DTLS-SRTP, 
HIP, ICE, TLS).


> Also, even if you don't have any SBCs, but you still have NATs, the
> calling user often needs to send something in order to open the NAT
> binding, and allow media plane traffic (including your identity
> exchange) from the remote end. If you use ICE, or stand-alone 
> STUN, you
> will have an open NAT binding, but if your terminal opens the network
> e.g. by sending dummy RTP packets, it will not be able to do 
> so until it
> has received the SDP answer.

* But if you haven't received the SDP answer, where are you sending
those dummy RTP packets (what is their destination IP address and 
UDP port)?

* If the NAT perform address-based filtering of incoming packets, 
it drop incoming UDP packets until the device behind the NAT
(the SIP UA, in our case) sends a packet to the IP address sending
the incoming packet.  The SIP UA would learn that IP address upon
receipt of the SDP answer.  Further, if the NAT is doing port
filtering of incoming packets, the SIP UA needs to know the UDP
port the external packet is arriving from, too (which also shows
up in the answer).  I point out the problem with port filtering
NATs because sending dummy UDP packets to the SBC's IP address 
is not sufficient for those kinds of NATs.  Similarly, if the 
NAT is symmetric (assigns a new UDP port for every new 
destination port or destination address the SIP UA sends to), 
sending dummy UDP packets won't be effective for symmetric
NATs, either.

> So, I also think your solution requires support of ICE/STUN, 
> and in the case of ICE it also requires that the SBCs 
> don't mess up the SDP so that ICE will not be used.

No, it does not.

For protection against simple From: spoofing, it is adequate to
simply validate the SIP headers and the signature.  For protection
against replay attacks, it is necessary for both SIP UAs (*) to
implement one of HIP, ICE, DTLS-SRTP, or TLS.  

  (*) The replay attack prevention and implementation of HIP, ICE
      (with the extension described in -wing-sip-identity-media),
      DTLS-SRTP, or TLS can be done by the SIP UA itself _or_ by 
      the SBC associated with the UA's signing domain -- such as 
      the Enterprise's SBC if the enterprise is signing the identity 
      (dwing@xxxxxxxxx, dwing@xxxxxxxxxx); or, if the SIP UA's 
      identity is signed by a Service Provider, the SBC operated by
      the service provider).

-d


> Regards,
> 
> Christer