Subject: RE: [Sip] B2BUA - Security

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Dec 2002 10:12:13 -0000

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.

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.

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.

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.

I guess if people liked this approach we would need to document somewhere
the UAS behaviour, namely: compare protected & unprotected copies & take
'appropriate' action on discrepencies. etc. Also to recommend that the UAC
include both copies when it uses S/MIME encryption.

Regards...Mark

> 3. rejects requests which use private addresses, and include in its 
> response an offer with corresponding public addresses.
> 
> hope this helps.
> thanks,
> -rohan
> 
> 
> 
> On Thursday, December 5, 2002, at 09:14 AM, Mahey, Sonit wrote:
> 
> > I agree with Jonathan.
> >
> > That brings up the question:
> > Is NAT traversal for encrypted SIP traffic addressed anywhere?
> >
> > - 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
> >>
> >> _______________________________________________
> >> 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
> >>
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Dec 2002 13:37:52 -0500

inline.

> 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.

> 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.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 9 Dec 2002 15:51:36 -0800

> modification needs to occur.

The midbox controller could propose a new SDP with public 
addresses/ports, which the UAC could actually sign.  I believe this 
will work, and requires minimal changes to SIP (at most a new response 
code).

Also if we separate the NAT problem into address/port discovery, and 
refresh, the UAC could use STUN to discover addresses, and just send a 
copy of the SDP with these recently discovered public addresses to the 
midbox controller, which just needs to *a* copy of part of the SDP to 
keep ports open.  It can even use session timer to avoid keeping state.

thanks,
-rohan

> for the solution. I believe there are many interesting requirements 
> here about disclosure of what is being done, that will strongly impact 
> the solution.
>
>> '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.
>
>> 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.
>
> be happy if we can get agreement on this general problem as one that 
> we need to solve.
>
>> 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.
>
> about the meaning of the multiple session descriptions - who set 
> which, and why.
>
> -Jonathan R.
> --

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 11 Dec 2002 09:03:00 -0000

OK - I'll go through some scenarios (host is agent, 'proxy' is agent, NAT
only, firewall only, NAT & firewall) and derive some requirements that
Midcom desires of SIP.

I assume these are application specific requirements which will be
generalised in a future round of development.  Is that the correct way to do
it?

Pete.

(to: and cc: list pruned in case it looks like spam!)

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Mark Watson" <[email-masked]>
Cc: "'Rohan Mahy'" <[email-masked]>; "Mahey, Sonit"
<[email-masked]>; "Pete Cordell" <[email-masked]>;
"Christian Huitema" <[email-masked]>; <[email-masked]>
Sent: 09 December 2002 18:37
Subject: Re: [Sip] B2BUA - Security

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Dec 2002 11:14:49 -0800

> only, firewall only, NAT & firewall) and derive some requirements that

good.

> generalised in a future round of development.  Is that the correct way 

yes, thanks.  whether it is a draft or just some text sent to the 
mailing list, lets discuss this in SIPPING, since it is a requirements 
discussion.

thx,
-rohan

>> here
>>> which
>>> only
>> we
>>> This approach would work through existing devices which 
>>> inspect/modify
> SDP.
>>>
>>> things
>> which,