RE: [Sip] SIP Identity using Media Path

["Dan Wing" <dwing@xxxxxxxxx>]

> >I think you meant to say "now assume that you will _not_ ..."?
> 
> What I meant to say was: Now you assume that you will have two-way
> connectivity before you have even sent the SDP answer :)

Thanks for clarifying.

This is how we meet our requirement to avoid clipping, and meet
the requirement of RFC3264 to have a bi-directional path for
sendrecv streams:

      "Once the offerer has sent the offer, it MUST be prepared to
      receive media for any recvonly streams described by that offer.
      It MUST be prepared to send and receive media for any sendrecv
      streams in the offer, and send media for any sendonly streams in
      the offer (of course, it cannot actually send until the peer
      provides an answer with the needed address and port information)."

This requirement is captured in section 3.1 and requirement 5 (R5) of 
draft-wing-media-security-requirements-04.txt.

> >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)?
> 
> That is what I am saying: the user needs to get the SDP 
> answer, so that it can open the NAT binding (and allow 
> incoming traffic)

Yes, in cases with certain kinds of NATs which filter, it is 
necessary to receive the SDP answer.  In cases with certain
other kinds of NATs that don't filter (or where there is no
NAT), it isn't necessary to receive the SDP answer.

However, for reasons unrelated to SIP-Identity-Media, it is
important to verify the certificate in the SDP answer matches
the certificate exchanged over DTLS (or TLS, if doing comedia).
Otherwise, an attacker can send a well-timed DTLS ClientHello 
or TLS ClientHello which will fool the endpoint into exchanging
application-layer data (SRTP or TLS-encrypted application data)
with the attacker.  Such an exchange with an attacker is
undesirable.   Thus, to reduce call setup time, it's useful
to perform the DTLS/TLS exchange prior to receiving the SDP
answer.  But it isn't necessary to do so.  Certainly you
don't want to do anything with the data you receive until
you have validated the DTLS/TLS certificate.

> >* 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
> >iltering 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.  
> 
> Ok, so let me put it this way: any feature in your solution that, in a
> NAT requirement, does require end-to-end connectivity before the SDP
> answer has been sent requires at least STUN (not necessarily ICE) - or
> some other mechanism which the NAT binding is opened without 
> having the
> remote SDP. And, if you use ICE, the SBCs must not modify the 
> SDPs in a way so that ICE is disabled.

draft-wing-sip-identity-media does not require end-to-end media 
path connectivity before the SDP answer arrives at the offer.

draft-wing-sip-identity-media provides identity protection in 
two "phases", to handle simple attacks and to handle more 
sophisticated attacks.  The first phase is the SIP header
signing, which is validated entirely without any regard to the
media path.  The second phase uses the media path, and protects
against replay attacks (where an attacker obtained a signed
Invite, for example, and replays it in order to ring your phone
again and appear to be the original caller.)  To protect against
that replay attack, you need to make the caller prove they know
something that only they know.  In sip-identity-media, I am
making the caller prove that he knows the private key associated
with the certificate (TLS, DTLS) or public key (HIP, ICE) that
is going to be used for the TLS, DTLS, or HIP call setup.  If 
he proves he knows that private key, it is safe and reasonable
to display the caller id.  If he can't prove that, he is an 
imposter.  If he refuses to prove that (or the media path is
blocked), you run the risk that -- after the media path is 
opened -- you will do the DTLS/HIP/TLS/ICE exchange and at
that time you will discover the user is an imposter.  That
discovery will occur after the phone has been rung and 
answered.  To me, that is a poor time to discover an 
imposter.  It's better than what we have today, though, so
I guess it _is_ forward progress and I could live with an
implementation that discovered an imposter after the phone
is answered.  It is certainly better than what we have 
today.  If such imposters become commonplace, users will
complain to their network providers about the middle-of-the-
night call alerting, phone answering, and attendant "Whoops,
sorry, that was an imposter.  We will send him a big fat
bill.  Please resume sleeping" messages displayed on their
handsets.

-d




> Regards,
> 
> Christer