Subject: RE: [Sip] B2BUA - Security

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Dec 2002 09:53:39 -0800

> From: Mahey, Sonit [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 9:14 AM
>
> I agree with Jonathan.
> 
> That brings up the question:
> Is NAT traversal for encrypted SIP traffic addressed anywhere?

There are two possibilities. If your application only uses UDP, it is
possible to use IPv4 and STUN to find out the "outside ports" for your
UDP traffic (check draft-ietf-midcom-stun-03.txt); you may need to use
the "a:rtcp" convention to encode port numbers in SDP (check
draft-ietf-mmusic-sdp4nat-03.txt). If you need to also support TCP, or
use IPSEC, or generally do away with the complications of NAT, the best
solution is to just move to IPv6; see Teredo
(draft-ietf-ngtrans-shipworm-08.txt) for one possible way to carry IPv6
across NAT, and 6to4 (RFC 3056 & 3068) for a possible way to upgrade the
NAT and make it an IPv6 router.

-- Christian Huitema
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Thu, 5 Dec 2002 12:33:45 -0600

Yes. See STUN.

/a

> -----Original Message-----
> Sent: Thursday, December 05, 2002 11:14
> To: 'Jonathan Rosenberg'; Pete Cordell
> Cc: Christian Huitema; [email-masked]
> Subject: RE: [Sip] B2BUA - Security
> 
> 
> I agree with Jonathan.
> 
> - sonit
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Thursday, December 05, 2002 11:28 AM
> > To: Pete Cordell
> > Cc: Christian Huitema; [email-masked]
> > Subject: Re: [Sip] B2BUA - Security
> > 
> > 
> > 
> > 
> > Pete Cordell wrote:
> > 
> > > I would say that encrypting and / or integrity checking 
> of SDP alone
> > > achieves absolutely no security benefit.
> > 
> > Really?? Wow. I actually think it prevents the most 
> > devastating attacks 
> > against SIP. These include:
> > 
> > 1. modifying SDP in transit to point media streams to an 
> intermediate 
> > recording device, allowing attackers to establish wiretaps
> > 
> > 2. downgrading any SRTP keying done in SDP, so that the media 
> > itself is 
> > not encrypted or integrity protected (this came up during 
> the mmusic 
> > session in IETF as a driver for S/MIME)
> > 
> > 3. launching a DoS attack by sending everyones voice traffic to the 
> > intended target. You get huge amplification gains here. Very 
> > appealing 
> > for hackers!
> > 
> > 
> > 
> > 
> > > 
> > > SDP really does two things.  It specifies transport 
> > addresses and chosen
> > > codecs.
> > > 
> > > Let's assume that you do encrypt the SDP and I can't read it.
> > > 
> > > I can have a good guess at the transport addresses in use 
> > from many of the
> > > other fields in SIP such as via lines, To, From, uri, 
> > contact, route etc.
> > 
> > Confidentiality is only one property of security. I am much more 
> > concerned about message integrity.
> > 
> > > (Put another way, encrypting SDP is another form of 
> > security by obscurity.
> > > And we all know what that means.)
> > 
> > I have no idea how you would arrive at such a conclusion. Security 
> > through obscurity means that information is not cryptographically 
> > protected, but encoded with a known process that is just a bit 
> > complicated. By definition, this is not encryption. Perhaps 
> you have 
> > discovered some new flaws in encryption technology?
> > 
> > -Jonathan R.
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Dec 2002 17:55:05 -0800

The sending UA places the result of the STUN translation in the SDP, not
the private addresses and port numbers.

> Sent: Thursday, December 05, 2002 10:00 AM
> To: Christian Huitema; Jonathan Rosenberg; Pete Cordell
> Cc: [email-masked]
> Thanks, Christian.
> Assuming IPv4 addresses and without delving into the draft RFC on
STUN:
> The SDP contains the RTP/RTCP port numbers that are private and these
are
> also required to be NAT'd. Now, if the SDP, which forms part of the
SIP
> body, is encrypted, how will RTP/RTCP ports be translated?
> 
> regards,
> - sonit
> 
> > From: Christian Huitema [mailto:[email-masked]]
> > Sent: Thursday, December 05, 2002 12:54 PM
> > To: Mahey, Sonit; Jonathan Rosenberg; Pete Cordell
> > Cc: [email-masked]

---

From: "Mahey, Sonit" <[email-masked]>
Date: Mon, 9 Dec 2002 13:40:49 -0500

Folks,

I agree with Jonathan. We need some definition around the work.

- sonit

> Sent: Monday, December 09, 2002 1:38 PM
> To: Mark Watson
> Cc: 'Rohan Mahy'; Mahey, Sonit; Pete Cordell; Christian Huitema;
> [email-masked]
> inline.
> Mark Watson wrote:
> > Rohan wrote:
> >  > In addition to Jonathan's approach to session policy, there is no
> >  > reason a middlebox controller can't be a proxy if it:
> >  >
> >  > 1. opens pinholes referenced in a clear text or integrity
> >  > protected SDP
> >  > 2. rejects requests with no readable SDP (the UA could
> >  > instead include
> >  > a full SDP, with keying material, encrypted with SMIME, 
> ****and an
> >  > abbreviated copy which is only integrity protected****).
> > 
> > 
> > I was about to write a draft suggesting exactly this.
> 
> THis is simply not sufficient.
> 
> It will suffice for firewalls, but not for NAT, where an actual 
> modification needs to occur.
> 
> I think that, per Pete's suggestion, the correct path forward is a 
> requirements document that describes the problem and the requirements 
> for the solution. I believe there are many interesting 
> requirements here 
> about disclosure of what is being done, that will strongly impact the 
> solution.
> 
> > 
> > As per Jonathan's draft there is a need for the UA to be able to 
> > 'declare' to network entities those parts of the SDP 
> information which 
> > are needed for the network entity to perform whatever service it 
> > performs (e.g. NAT or Firewall control). But the UA should 
> not have to 
> > declare the whole SDP, and the terminating UA should be 
> able to tell if 
> > a network entity has modified these parameters.
> 
> Sounds like we are beginning the requirements work here...
> 
> > 
> > Rather than putting this information into new SIP headers, we could 
> > include two copies of the SDP. One copy is unprotected and 
> contains only 
> > the information that the UE wishes to 'declare' to the 
> network entities. 
> > The other copy is protected and contains the full information.
> 
> I think we can leave the header/body debate for down the 
> road. I would 
> be happy if we can get agreement on this general problem as 
> one that we 
> need to solve.
> 
> > 
> > This approach would work through existing devices which 
> inspect/modify SDP.
> > 
> > I'm not sure how an existing S/MIME compliant client would 
> behave on 
> > receiving these two copies. If it uses the unprotected SDP, 
> then things 
> > are no worse than the present situation - the call suceeds, 
> but without 
> > the advantages of S/MIME. If it uses the protected SDP 
> (which has not 
> > been modified by the NAT controlling device), then the call 
> fails, but 
> > this is still no worse than the present situation.
> 
> It comes down to disclosure. The message needs to convey information 
> about the meaning of the multiple session descriptions - who 
> set which, 
> and why.
> 
> -Jonathan R.
> --