Subject: [Sip] Question on SIP Security considerations for future extensions

From: Dean Willis <[email-masked]>
Date: Mon, 13 Aug 2007 16:19:21 -0500

I'm having quite an interesting conversation with Sandy Murphy (cc'd)  
who was tasked by sec-dir to review one of our drafts (draft-ietf-sip- 
answermode). This draft has some rather interesting security issues,  
since if implemented incorrectly and then abused it could allow an  
attacker to "bug your phone" -- that is, turn it into a remote  
listening device. Similar attacks could also be used to run up the  
victim's connectivity bill, run down the device's battery, aggravate  
the "voice hammer" DOS attack, and so on.

This lead us into a discussion of the SIP security model in general.  
Most SIP practitioners who have been at it for awhile know that if  
the proxies we have decided to trust suddenly decide to get  
malicious, then we're very much at their mercy. They can do all sorts  
of things, including routing our media through interceptors, mangling  
SDP payloads, injecting (or blocking) instant messages, altering  
presence information, and so on.

But this aspect of SIP is not obvious to naive implementors, or even  
to less naive security types.

Maybe every SIP extension document should include a boiler-plate  
reminder about the sensitivity of proxies, then go on to enumerate  
and describe the new ways that malicious proxies (should there be  
such a thing) can wreak havoc using the extension being documented.

what do you folks think?

1) Could a reasonable "How you could be violated by trusted proxies  
that turn rogue" boilerplate be drafted?
2) Would the practice of repeating this in drafts help or hurt us?
3) Would it be useful for us to document how each extension could be  
used by a rogue proxy?

--
Dean

_______________________________________________
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: "Dan Wing" <[email-masked]>
Date: Mon, 13 Aug 2007 16:09:35 -0700

...
> 3) Would it be useful for us to document how each extension could be  

In Chicago when I presented draft-wing-sip-identity-media, Cullen
said transitive trust of the entire SIP network for Identity was 
fine, and RFC4474 was sufficient even with SBCs in the network.  At 
the meeting, only Hadriel Kaplan said transitive trust for identity 
was not desirable with SBCs in the network.  If identity can be 
spoofed by any trusted proxy in the SIP network you're connected 
to, you're going to be unable to gain strong identity that's needed 
for sip-answermode (defense mechanism #1 identified in section 7.3
of draft-ietf-sip-answermode-04) or even the strong identity needed
to reliably display Caller-ID.

However, based on the tepid response to sip-identity-media in
Chicago, my conclusion is there is high comfort in the working 
group that proxies and SBCs do not go rogue.

I found this surprising, and I continue to find this surprising.

To your questions, I think such text would be valuable, but to
really be useful we'd need an I-D that analyzed RFC3261 itself
under the same microsocope.  Such a document could start with
the examples from your original post.

-d

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 13 Aug 2007 16:52:03 -0700

Dan,

>there is high comfort in the working group that proxies and SBCs do not

>go rogue.

This is really not surprising given that nobody in the meeting was
prepared to report on _measured_ incidents vs. voicing opinions.

I share your concern since a stateful SBC, that also handles media is
the ideal target for evil doers on the Internet. Where else would
someone intercept phone calls and the signaling, all conveniently in one
place?

Now with peering, a questionable chain of trust develops that is even
more likely to break.

If there were only a way to collect incident reports...

But maybe we are barking up the wrong tree: The purpose here is not
security but usage billing and whenever possible, collecting roaming
charges.

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 6:10 PM
To: 'Dean Willis'; 'sip List'
Cc: 'Sandy Murphy'
Subject: RE: [Sip] Question on SIP Security considerations for
futureextensions

...

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Aug 2007 19:56:48 -0400

Maybe such a policy would encourage the adoption of sipsec.

	Paul

Dean Willis wrote:
> who was tasked by sec-dir to review one of our drafts 
> (draft-ietf-sip-answermode). This draft has some rather interesting 
> security issues, since if implemented incorrectly and then abused it 
> could allow an attacker to "bug your phone" -- that is, turn it into a 
> remote listening device. Similar attacks could also be used to run up 
> the victim's connectivity bill, run down the device's battery, aggravate 
> Most SIP practitioners who have been at it for awhile know that if the 
> proxies we have decided to trust suddenly decide to get malicious, then 
> we're very much at their mercy. They can do all sorts of things, 
> including routing our media through interceptors, mangling SDP payloads, 
> injecting (or blocking) instant messages, altering presence information, 
> and so on.
> 
> But this aspect of SIP is not obvious to naive implementors, or even to 
> less naive security types.
> 
> reminder about the sensitivity of proxies, then go on to enumerate and 
> describe the new ways that malicious proxies (should there be such a 
> thing) can wreak havoc using the extension being documented.
> 
> what do you folks think?
> 
> 1) Could a reasonable "How you could be violated by trusted proxies that 
> turn rogue" boilerplate be drafted?

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Aug 2007 21:44:12 -0700

On Aug 13, 2007, at 4:09 PM, Dan Wing wrote:

> Cullen
> fine

Uh, I don't think I exactly said that but if I did, I like to  
contradict myself now :-) Actually if I thought this, it seems that  
the From header would be fine and we would have no need for 4474 or  
3325.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Aug 2007 22:02:01 -0700

I will note that we do have security mechanism to provide  
confidentially over the bodies (but not headers) for attacks from  
proxies we do not have a trust relationship with - and this is one of  
the aspects used in determining if certain semantics might be better  
in a body or header.

Cullen <with my individual hat on>

PS - I fail to see how sipsec will help with the basic problem of if  
Alice sends a call to a proxy and the proxy routes the call to some  
evil user instead of sending it to Bob.

On Aug 13, 2007, at 4:56 PM, Paul Kyzivat wrote:

>> I'm having quite an interesting conversation with Sandy Murphy  
>> (cc'd) who was tasked by sec-dir to review one of our drafts  
>> (draft-ietf-sip-answermode). This draft has some rather  
>> interesting security issues, since if implemented incorrectly and  
>> then abused it could allow an attacker to "bug your phone" -- that  
>> is, turn it into a remote listening device. Similar attacks could  
>> also be used to run up the victim's connectivity bill, run down  
>> the device's battery, aggravate the "voice hammer" DOS attack, and  
>> so on.
>> This lead us into a discussion of the SIP security model in  
>> general. Most SIP practitioners who have been at it for awhile  
>> know that if the proxies we have decided to trust suddenly decide  
>> to get malicious, then we're very much at their mercy. They can do  
>> all sorts of things, including routing our media through  
>> interceptors, mangling SDP payloads, injecting (or blocking)  
>> instant messages, altering presence information, and so on.
>> But this aspect of SIP is not obvious to naive implementors, or  
>> even to less naive security types.
>> 1) Could a reasonable "How you could be violated by trusted  
>> proxies that turn rogue" boilerplate be drafted?
>> 3) Would it be useful for us to document how each extension could  
>> be used by a rogue proxy?
>> -- 
>> Dean

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Aug 2007 22:11:31 -0700

> > Cullen said transitive trust of the entire SIP network for 
> > Identity was fine
> 

RFC4474 and RFC3325 are useful and valuable and necessary.  I have
not said otherwise.  Thing is, their applicability on the SIP networks
being designed and deployed is limited, much as SIP's early design
had UACs sending SIP directly to UASs and slowly proxies became
necessary due to NATs, firewalls, network-provided QoS (via SDP
snooping), and so on.

I'm not sure why you removed ", and RFC4474 was sufficient even with 
SBCs in the network" from my sentence, as it was relevant to the
meaning of my statement.  As I explained in Chicago in the last timeslot
in SIP, RFC4474 doesn't work if the Invite traverses SBCs that are
not owned by the originating domain's authentication agent.  SIP 
networks deployed and operating today have SBCs that aren't operated 
by the originating domain's authentication agent.  Thus, I don't 
see how we get identity in a network with SBCs, except via 
transitive trust:  I trust my provider to have validated the
signature they received, who trusts the upstream provider to have
validated the signature they received, and so on.  This has 
security properties identical to using P-A-I between those 
domains.

draft-ietf-sip-answermode is only one example of the significant 
need for identity in SIP.  Without identity that works across 
SIP networks being built today, we can't provide the foundation 
for its necessary authorization mechanism.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2007 07:54:04 -0400

Cullen Jennings wrote:
> 
> I will note that we do have security mechanism to provide confidentially 
> over the bodies (but not headers) for attacks from proxies we do not 
> have a trust relationship with - and this is one of the aspects used in 
> determining if certain semantics might be better in a body or header.
> 
> Alice sends a call to a proxy and the proxy routes the call to some evil 
> user instead of sending it to Bob.

True. But I think that is a lesser problem, if you can determine you 
have reached the wrong person. I think it is a compromise people are 
willing to make - to find a callee.

	Paul

>>> could allow an attacker to "bug your phone" -- that is, turn it into 
>>> a remote listening device. Similar attacks could also be used to run 
>>> up the victim's connectivity bill, run down the device's battery, 
>>> aggravate the "voice hammer" DOS attack, and so on.
>>> --Dean

---

From: "Arun Punj (WD/EUS)" <[email-masked]>
Date: Tue, 14 Aug 2007 08:53:13 -0500

Folks, 
I have a simple question/comments see below.

thanks
Arunrajan

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 7:54 AM
To: Cullen Jennings
Cc: sip List; Sandy Murphy; Dean Willis
Subject: Re: [Sip] Question on SIP Security considerations for
futureextensions

> I will note that we do have security mechanism to provide
confidentially 
> Alice sends a call to a proxy and the proxy routes the call to some
evil 

True. But I think that is a lesser problem, if you can determine you 
have reached the wrong person. I think it is a compromise people are 
willing to make - to find a callee.
[ap] 
Is there a way to find out that you have reached the wrong person?
Because it would seem, that is the very basis of security, If alice
calls bob, and is connected to charles, or worse is connected to bob
through charles - the call is not secure. It would seem that RFC 4474,
does not
prevent this from happening and is kind of pointless for that reason. I
have not read any of the sipsec work so maybe I am just being ignorant,
right now. 

As a general principle, I feel very uncomfortable with high level of
*trust* in the network entities. I think a model like TLS/SSH where the
endpoints verify each other is desirable ( If not imperative) for sip.
That is caller/callee must be able to authenticate/prevent man in the
middle with as little help from external entities as possible, maybe all
I can trust is my proxy/HLR/Authenticationserver with each I have a PSK
trust relationship.
I understand this requires an extensive infrastructure support ( for
certs/keys) etc specially if conference calls are to be supported, but
that is all the more reason to start now.

[\ap] 

Paul

>>> I'm having quite an interesting conversation with Sandy Murphy
(cc'd)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2007 11:27:54 -0400

> I have a simple question/comments see below.
[snip]
> Is there a way to find out that you have reached the wrong person?

Not in general. Its not well defined who the *right* person is if 
forwarding is involved.

There have been proposals to push all forwarding/redirection back to the 
UAC, so that it can make its own decision is the new target is an 
acceptable target to it. I believe that is necessary to make sipsec work.

The sipsec draft establishes an e2e TLS connection. This allows the cert 
of the UAS to be verified. Of course it will only work if the UAS *has* 
a cert that can be verified by the UAC, which brings up many issues of 
certificate management, etc. Its far from a done deal.

> I can trust is my proxy/HLR/Authenticationserver with each I have a PSK

Yeah, a lot of people share your concern.

The need for proxies was motivated initially by the lack of fixed 
addresses for phones. Hence the need for registration and retargeting 
from an AOR to the address of the phone.

However, this is pretty similar to not knowing what server you want to 
contact on the web. When you don't know you use a search engine to find 
some candidates. Then you can, if you wish, establish a secure 
connection to one of the candidates. In the end you can know you are 
talking to somebody who has rights to the address you are connected to. 
But you still have to trust a bunch of infrastructure to know that is 
who you want to be talking to.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Aug 2007 11:10:05 -0500

Cullen Jennings wrote:
> the aspects used in determining if certain semantics might be better  in 
> a body or header.
> 

The assumption in sipsec is that Bob has a X.509 cert that Alice
verifies directly.  It may be a self-signed cert, or it may be rooted
in a common CA.  If former, then a fingerprint could be exchanged
a-priori between Alice and Bob.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Aug 2007 11:17:52 -0500

On Aug 14, 2007, at 12:02 AM, Cullen Jennings wrote:

> proxies we do not have a trust relationship with - and this is one  
> of the aspects used in determining if certain semantics might be  
> better in a body or header.
>
> PS - I fail to see how sipsec will help with the basic problem of  
> if Alice sends a call to a proxy and the proxy routes the call to  
> some evil user instead of sending it to Bob.

Since the TLS connection of sipsec is established UA to UA, the  
evildoer in your example would have to have Bob's cert (aka "private  
key"). If the evildoer does not have Bob's cert, Alice will be able  
to tell that the evildoer is not Bob.

Of course, this requires a workable public key infrastructure. But  
then we think we're getting one of those from draft-ietf-sip-certs,  
so maybe this is doable after all.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Aug 2007 11:19:15 -0500

> better in a body or header.

And you've got working examples of this security mechanism in  
deployed networks?

--
Dean

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 14 Aug 2007 13:38:22 -0400

This is related to a point that someone [My apologies for not remember 
who] raised at the Chicago meeting:

What problem will sipsec solve that existing (and not well deployed) 
security measures do not solve?

Given that current transitive-trust models of security are 
well-deployed, my inclination is that it is important to provide 
guidence to on the strengths and weaknesses of transitive-trust models 
(in the hope that we can dissuade people from making false assumptions 
about the systems they are deploying). I'm less convinced that it's 
important to move forward with a brand new security measure, unless we 
have good reason to believe that it will be more effective than existing 
mechanisms.

- Matt Lepinski :->

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Aug 2007 13:13:47 -0500

On Aug 14, 2007, at 12:12 PM, Matt Lepinski wrote:

> This is related to a point that someone [My apologies for not  
> remember who] raised at the Chicago meeting:
>
> What problem will sipsec solve that existing (and not well  
> deployed) security measures do not solve?

The goal of SIPSEC is eliminating the requirement of transitive  
trust. We still have a reliance on request routing functionality to  
make the initial delivery of the CONNECT message, but after that the  
only attack that an intermediate proxy could launch would be to stop  
forwarding messages. This is much less insidious than subtly altering  
the contents of messages in order to delivery the appearance of  
normality when in fact an attack has been effected, or of disclosing  
sensitive elements of the messages to third parties so that attacks  
can be effected by those parties.

While the documented-but-undeployed S/MIME approach appears to offer  
protection from proxies that subtly alter the bodies of messages, the  
protection for header-level alteration is weaker, and even in the  
best case a great deal of information potentially useful to attackers  
is visible to the proxies (and hence potentially compromised to  
attackers). SIPSEC appears to offer fairly complete integrity and  
privacy protection for all headers and body parts following the  
initial CONNECT message, and the initial CONNECT is designed to  
disclose as little sensitive information as possible.

> Given that current transitive-trust models of security are well- 
> deployed, my inclination is that it is important to provide  
> guidance to on the strengths and weaknesses of transitive-trust  
> models (in the hope that we can dissuade people from making false  
> assumptions about the systems they are deploying). I'm less  
> convinced that it's important to move forward with a brand new  
> security measure, unless we have good reason to believe that it  
> will be more effective than existing mechanisms.
>

Yes, that's exactly the goal of the proposal that started this  
thread: to find a way to more completely describe the strengths and  
weaknesses of the current transitive trust models and then require  
new extensions to document how the extension interacts with those  
aspects of the operational environment. Whether we like the current  
operational environment or no, we still need to understand it very  
clearly, because it is real and we live in it today. More so, we need  
to clearly understand the security impacts of new extensions.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Aug 2007 12:29:25 -0700

On Aug 14, 2007, at 10:12 AM, Matt Lepinski wrote:

> guidence to on the strengths and weaknesses of transitive-trust  

yes - that makes sense.

The other thing that I think is important is considering sipsec is  
why is the proxy in the path in the first place? If the proxy does  
not need to see or change any of the headers why is the message  
traversing the proxy at all?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Aug 2007 16:14:01 -0500

Cullen Jennings wrote:
> The other thing that I think is important is considering sipsec is  why 
> is the proxy in the path in the first place? If the proxy does  not need 
> to see or change any of the headers why is the message  traversing the 
> proxy at all?

A couple of reasons: (a) routing across the normal SIP proxy mesh to
reach the recipient (UAC may not know the specific network identifiers
of the UAS), and (b) UAS may be behind a NAT/FW and not able to
establish a direct communication with the UAC without a proxy.

In private emails, Frank Miller has proposed an optimization
to the proxy-routed sipsec model whereby the endpoints obtain a
globally visible IP address (thru STUN or similar means) and
then exchange signaling directly between them.  We are currently
debating this optimization among us before presenting it to
a larger audience.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Aug 2007 18:40:48 -0500

Look, my question about security documentation for SIP extensions had  
nothing to do with SIPSEC and everything to do with documenting the  
current please-molest-me proxy-mediated transitive-faith-in-goodness  
I-believe-my-operator-cares-for-me model of SIP security. And we DO  
need to document this model better -- the question is how.

So I'm changing the thread subject for further discussion on SIPSEC.

> traversing the proxy at all?

see draft-ietf-sip-outbound.

Outbound proxies do NOT really need to see or change any of the SIP  
headers. But they're very, very useful from a NAT traversal perspective.

With SIPSEC, the outbound proxy sees CONNECT, routes it, then  
establishes a packet-forwarding channel. The UAs do keepalive on this  
channel. And everybody is happy and secure.

Of course, we could probably have done the same thing with STUN  
relay, if we had a way to route STUN-relay requests or REGISTER  
contacts containing vectors of STUN relays. But we don't, yet.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 15 Aug 2007 02:00:02 -0400

I think Cullen was being facetious.  Many of the hops along the path do not
insert themselves purely to aid your UAC in finding the UAS.  Otherwise they
would mostly be stateless or redirect proxies.
Obviously some do only that, but my guess is that's the exception not the
rule.

[flame retardant enabled]
There are all forms of stateful proxies (and more) along the path between a
UAC and UAS, and I seriously doubt their owners are interested in removing
them from it.  Ignoring all the things boxes do these days, even from a
"security" perspective many of their owners see it in the complete reverse
model - the endpoints are about the least secure thing they can imagine.  No
way are they letting John Doe's softphone-de-jour at wildwest.com exchange
SIP directly with one of their SIP subscribers, pstn gateways, voicemail
servers, etc.  

Seems to me that sort of thing is a fine argument/use for p2psip.

-hadriel

> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2007 7:41 PM
> To: Cullen Jennings
> Cc: Matt Lepinski; sip List; Paul Kyzivat; Sandy Murphy
> Subject: SIPSEC questions (Was Re: [Sip] Question on SIP
> Securityconsiderations for future extensions)
>

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 14 Aug 2007 13:12:04 -0400

- Matt Lepinski :->

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Aug 2007 10:37:57 -0400

I'm replying to Dean's original message so that I'm not deep down in the 

 > need to document this model better -- the question is how.

Here's my proposal:

First, we need to document the situation as it stands, given the proxy 
model and security mechanisms defined in RFC 3261 and relevant 
extensions.  I.e., in the current system, here's the base 
(please-molest-me) model, here's what proxies can do to screw you up in 
this model, and here's the sorts of assurances you can get by employing 
some security features.

Second, rather than requiring boilerplate in documents defining new 
extensions, they should comment on how the extension affects the model 
described in the above document -- either providing additional security 
(e.g., by limiting proxy capabilities like SIPSEC) or by introducing 
additional risks (e.g., by increasing proxy capabilities, like 
answer-mode).  This discussion could be a required subsection of the 
Security Considerations section.

I think that this would encourage people to give explicit consideration 
to the sorts of risks Sandy noted in the answer-mode draft, and to think 
about how they might fix or avoid them.

--Richard