Subject: [Sip] draft-state-sip-relay-attack-00

From: Raphael Coeffic <[email-masked]>
Date: Wed, 04 Mar 2009 11:34:39 +0100

Hello,

a new internet draft has been published concerning the relay attack on 
digest authentication and SIP. The attack itself has been first 
disclosed 2 years ago by the maydnes team from the french INRIA. Until 
now, no document has been pushlished that documents the attack and 
provides guidance to SIP operators or handset manufacturers.

http://tools.ietf.org/html/draft-state-sip-relay-attack-00

The appropriate mitigations of problem resolutions are still not 100% 
clear. We hope that this draft can help start a discussion on how to 
best resolve this problem.

Regards,

Raphael Coeffic.
(on behalf of all the authors of this draft)

---------------------------------------------------------------------------------------------------

Filename:	   draft-state-sip-relay-attack
Version:	   00
Staging URL:	   http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt
Title:		   SIP digest authentication relay attack
Creation_date:	   2009-03-02
WG ID:		   Indvidual Submission
Number_of_pages: 18
Abstract:
The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism
for creating, modifying, and terminating sessions with one or more
participants.  This document describes a vulnerability of SIP
combined with HTTP Digest Access Authentication [RFC2617] through
which an attacker can leverage the victim's credentials to send
authenticated requests on his behalf.  This attack is different from
the man-in-the-middle (MITM) attack and does not require any
eavesdropping, DNS or IP spoofing.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Mar 2009 13:20:29 -0800

Thanks for publishing that attack.  It has similarities with the attack
described by Hadriel in
http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Raphael Coeffic
> Sent: Wednesday, March 04, 2009 2:35 AM
> To: [email-masked]
> Subject: [Sip] draft-state-sip-relay-attack-00
> 
> Hello,
> 
> Staging URL:	   
> http://www3.ietf.org/proceedings/staging/draft-state-sip-relay
> -attack-00.txt
> _______________________________________________
> Sip mailing list  https://www.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: Theo Zourzouvillys <[email-masked]>
Date: Wed, 4 Mar 2009 23:23:00 +0000

On Wed, Mar 4, 2009 at 10:34 AM, Raphael Coeffic <[email-masked]> wrote:

> The appropriate mitigations of problem resolutions are still not 100% clear.
> We hope that this draft can help start a discussion on how to best resolve
> this problem.

Hi Raphael,

Thanks for documenting this!

page 10:

   It is worth noting that the protection
   provided on the request URI is purely theoretical, as [RFC3261]
   introduces an exception to the request URI checking required by
   [RFC2617] in section 22.4:

Another important consideration to keep in mind while thinking about
solutions is that the Contact header in the dialog creating request
can be pretty much anything bob likes if he also adds a Record-Route
header in, leading to the dialog target URI at alice's UA being
whatever bob wants, and thus the Authentication header can be
manipulated to contain whatever the attacker wants in the uri
parameter.  To explain - consider Figure 1 in the draft

F1 could be sent by [email-masked] as:

  INVITE sip:[email-masked] SIP/2.0
  Contact: <sip:[email-masked]>
  Record-Route: <sip:[email-masked];lr>

thus, when alice creates the dialog, the remote URI will indeed be
[email-masked], and your in-dialog F10 message will be:

   F10 INVITE Alice -> Bob

      INVITE sip:[email-masked] SIP/2.0
      Route: <sip:[email-masked];lr>
      Proxy-Authorization: Digest username="alice", realm="proxy.com",
       uri="sip:[email-masked]", nonce="f84f1cec41e6cbe5aea9c8e88d359543",
       response="3bea678acef9875433487f23a567d876",
       opaque="", algorithm=MD5
      Content-Type: application/sdp
      Content-Length:...

presto - the authentication header now even contains the URI you want
to call.  note that a re-INVITE could also be done to change the
target URI a few times to get different Authentication headers with
different URIs in, all legitimate.

As to the potential solutions: both only accepting from registered
contact or any attempt at avoiding sending re-INVITE [1] are in my
opinion unfeasible and broken - i'll have some thought on others,
though :-)

 ~ Theo

1 - REFER is another in-dialog method that could be abused - an OOD
REFER may be accepted with authentication by - for example - a PSTN
gateway.  Social engineering of alice could result in alice's UA
sending a REFER that could then be used.

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 05 Mar 2009 10:47:52 +0100

> http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack.
Yes, it also modifies part of the request which are not signed by the 
authentication/signature algorithm. I should mention this draft in a 
later version.

However, the goal is not the same. Hadriel's draft is focused on 
impersonation, whereby the other draft is focused on breaking the 
authentication done at the proxy. The second difference is that it works 
right now with any publicly reachable SIP provider.

Raphael.

---

From: Michael Procter <[email-masked]>
Date: Thu, 05 Mar 2009 09:56:11 +0000

Raphael Coeffic wrote:
> authentication done at the proxy. The second difference is that it
> works right now with any publicly reachable SIP provider.
>

I'm intrigued by the variation in fig2.  How often are you finding two
proxies in different administrative domains that use the same
credentials?  Or is the attack more focussed towards Alice using
multiple sets of credentials?

I think that the variation in fig3 can be addressed to some degree by
using GRUU, but I don't think that completely solves the problem.

Regards,

Michael

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 05 Mar 2009 10:59:43 +0100

> multiple sets of credentials?
They are not using the same credentials, which is the reason why 
'proxy.com' won't remove Alice's credentials from the request, and thus 
enable the attack.

> using GRUU, but I don't think that completely solves the problem.
I am not quite sure that I understand how this helps: could you develop 
your thoughts a little bit more?

Regards,
Raphael.

---

From: Jan Janak <[email-masked]>
Date: Thu, 5 Mar 2009 11:59:57 +0100

> multiple sets of credentials?

Yes. The scenario in fig2 shows that such attack is possible even if Alice can
receive SIP requests from its outbound proxy only (or one of its outbound
proxies), either because her phone is configured so or because it is behind
NAT.

Even if the outbound proxy removes digest credentials that belong to its
administrative domain before forwarding SIP requests downstream, you can still
obtain digest credentials for another administrative domain through this
outbound proxy from Alice if her phone is configured with multiple sets of
credentials.

If you have a phone which is configured to use two different ITSPs and has two
sets of digest credentials then it is most likely vulnerable to this kind of
attack.

  Jan.

---

From: Michael Procter <[email-masked]>
Date: Thu, 05 Mar 2009 11:04:58 +0000

Raphael Coeffic wrote:
> 'proxy.com' won't remove Alice's credentials from the request, and
> thus enable the attack.

I see - it wasn't entirely clear from your text which case you were
addressing.  So that scenario is essentially the normal MITM digest
attack.  Whenever you receive a challenge, you can't really authenticate
the server that is challenging you to determine whether you should issue
a valid response or not.

> I am not quite sure that I understand how this helps: could you
> develop your thoughts a little bit more?

Sorry - I mistyped!  What I meant to say was that 'outbound' addresses
the problem to some degree.  To expand on that a little, the key in fig3
is for Bob to be able to send a response directly to Alice, without
going through the proxy.  In the hosted scenario (which I considered
first), Alice is typically behind a NAT/FW and uses outbound to maintain
flows to proxy.com.  As a consequence of this, Alice should only act
upon responses received over these flows.  This would defeat the attack
in fig3, since Bob's altered response would probably not even reach
Alice, let alone be acted upon.

In the non-hosted scenario, where Alice and proxy.com are on the same
network (i.e. without NAT/FW issues) such as might be the case in a
typical enterprise deployment, then outbound wouldn't be used.  But in
this case, I would expect the enterprise firewall to prevent
communications from Bob to Alice, except when mediated by an appropriate
device (such as proxy.com).  Again, the scenario in fig3 would be defeated.

That isn't to say that the attack in fig3 isn't a real attack, only that
I wouldn't expect most deployed networks to suffer from it.

Regards,

Michael

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 05 Mar 2009 12:12:40 +0100

Hello Michael,

> the server that is challenging you to determine whether you should issue

That's true. The novelty is that such a MITM attack can be induced by 
SIP means, without to much interventions into the network topology (no 
DNS or ARP spoofing for example).

> device (such as proxy.com).  Again, the scenario in fig3 would be defeated.
Imho, not necessarily. It is very easy to forge an IP (that of the 
proxy) if you only need one-way communication, which is the case for the 
200 reply. This means that it should be quite easy to get this reply 
directly to Alice. The question is what Alice and the outbound proxy 
will do after that.

> I wouldn't expect most deployed networks to suffer from it.
You may be right.

Best regards,
Raphael.

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Thu, 5 Mar 2009 14:40:54 +0100 (CET)

Hello,

first of all I agree that the draft describes a potential problem.

One thing which is not that obvious but is implictly a requirement for the
attack: the proxies has to challenge in-dialog requests. I do not see a
big benefit in challeging in-dialog requests as these are hopefully
rejected by the remote side if no matching dialog exists. If the UA would
know that his proxy does not challenge in-dialog requests it could simply
ignore the challenge :-)

Some more comments:

Figure 1:
- As the draft already states this direct attack becomes inpossible if
Alice UA accepts incoming requests only from one of its proxys (we have to
keep in mind that we rely here on pure IP layer security which is weak as
we all know).
- Additionally Alice UA should notice that the call got established
without a route set. And without any Route set I would not see why the UA
should get a challenge at all. But I admit that such a check most likely
does not exist in UA today.

Figure 2:
- If p2.com uses a different realm then proxy.com you should mention in
your draft that Bob needs to know that Alice has accounts configured for
both servers in her UA.
- I never unterstood why a proxy should pass through the authentication
request from a foreign domain. In which scenario do I have credentials for
two different domains, but the traffic including authentication is passed
through only one of them?
Sure I could have a call forwarding from p2.com to proxy.com. Again only
if p2.com challenges in-dialog requests the problem arrises with this call
forwarding.
- Another possible improvement for an UA would be to strictly bind the
credentials to one proxy. Which means it would only answer challenges for
proxy.com if the request came IP wise from proxy.com and it would not
answer challenges for other proxies if they arrive IP wise from proxy.com.
This improvement does not work if you use daisy chained proxy with
authentication for outbound calls (but I have never seen or heard of such
a setup), or if the proxy with active call forwarding challenges in-dialog
requests.
- If we admit that this authentication pass through is of no real use,
either Alice UA could ignore it, or proxy.com could simply strip the
authentication from the foreign domain p2.com.
- If we still need authentication pass through proxy.com could at least
check that it does not pass through challenges with the same realm as its
own one (which brakes daisy chains of challenging proxy with identical
realms - which is hopefully not too comon).

I admit that my comments are no real solution for the problem itself and
some of them would first need to be implemented. But hopefully they help
to improve the situation.

Regards
  Nils Ohlmeier
  VoIP Freelancer

> http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt

---

From: Theo Zourzouvillys <[email-masked]>
Date: Thu, 5 Mar 2009 14:31:05 +0000

> We hope that this draft can help start a discussion on how to best resolve

After more thinking about this, I don't think this document presents
anything other than there are poorly implemented SIP endpoints and
proxies out there - as there is nothing wrong with SIP itself [1] in
these attacks:  It all boils down to UA vendors currently giving
credentials to anyone who asks for them, even if they shouldn't be.

All of the scenarios you mention in this document apply directly to
proxy authentication in the case where a UA would use outbound
authentication with it's proxy.  A UA only ever sending proxy
credentials to it's proxy seems like a dead simple and sensible thing
to do (and although i'm not really surprised UAs don't do this, i'll
pretend to be), and makes all the attacks you list just go away.

The only issue i see is in fig 3, how to identify a next hop is
actually proxy.com and not bob, as a proxy will commonly RR with a URI
such as node-01.proxy.com instead of proxy.com, or even use an IP
address in it.  The first, and most and correct way is use TLS or DTLS
with mutual auth, and you can verify that the next hop is really your
proxy and thus it's ok to send credentials to it.  The second way is
to always send requests to proxy.com (i.e, using outboind), even in
dialog ones (and indeed many UAs have a "send in-dialog requests via
outbound proxy" option,which makes this attack go away) - although
this might breaks some broken SBCs out there that SPs deploy today.
The third option (and most ickly and hacky) it to build and keep a
whitelist of IP addresses that proxy.com is, and ensure the SP only
ever record-routes using an IP address that a forward lookup on
proxy.com would resolve to.  crappy but in reality mostly works today,
as long as devices are sensible and do things like refresh after TTLs
expire on RRsets.

So, what does need to be done is beat UA vendors and SIP operators
with a great big security clue stick (how that's done i'd love to
know.  My stick is almost broken, and even when applied directly,
mostly ineffective.) - perhaps a BCP to highlight the issues?

However, you don't cover the more interesting cases of multi-hop proxy
authentication or end-to-end WWW authentication: these are the harder
ones to deal with, and may result in some "real" issues in SIP itself
rather than shoddy implementations and insecure proxies.

 ~ Theo

1 - heh. sarcasm.

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 05 Mar 2009 15:41:50 +0100

Hi Theo,

I really think that mutual authentication is the way to go. 
Unfortunatly, there is nothing deployed in this direction right now. 
Most providers (at least in germany) try to tackle those issues by 
separating networks. The SIP phones are then jailed into things like 
dedicated virtual circuits (on the DSL level). On the provider-side, 
they use the full panel of firewalls to get the full control of 
everything. This is definitely not the way to go.

Having the BCP gathered into this document (or another one, I don't 
care) would be a good thing to do. If you let people think by 
themselves, you might end-up with the situation we have right now.

> rather than shoddy implementations and insecure proxies.

If you provide me with the input, I'd be very happy to document those 
issues.

Regards
Raphael.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Mar 2009 07:36:22 -0800

> Dan Wing wrote:
> > Thanks for publishing that attack.  It has similarities 
> > with the attack described by Hadriel in
> authentication done at the proxy.

By breaking the authentication the attacker can impersonate
another user.  For example, that proxy might create an RFC4474 
signature.

> The second difference is that it works right now with any 
> publicly reachable SIP provider.

Yes, I agree that makes it much more interesting.

-d

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 05 Mar 2009 16:45:52 +0100

> another user.  For example, that proxy might create an RFC4474 
Another interresting application indeed! As it looks like, a lot of 
people on the list have very good ideas that we will have to document in 
version 01 (if it is the will of the WG, of course!).

Regards
Raphael.

---

From: Theo Zourzouvillys <[email-masked]>
Date: Thu, 5 Mar 2009 16:01:47 +0000

> I really think that mutual authentication is the way to go.

MTLS is indeed a good way to go for so many reasons, but it's not the
only way this can be fixed.

For the fig 3 attack, receiving the response down the same stream
oriented connection indicates it came form the proxy, not the
attacker.  In the case of datagram, an adjustment to
draft-zourzouvillys-via-cookies to get the proxy to re-add the cookie
value in the response would solve the direct-to-source response
scenario without having the evil DNS lookup hacks in place.

> Having the BCP gathered into this document (or another one, I don't care)
> would be a good thing to do. If you let people think by themselves, you
> might end-up with the situation we have right now.

We'll end up with insecure implementations whatever we do - although
education is the key to minimising them.

> If you provide me with the input, I'd be very happy to document those

i'll see if i can find time :-)

 ~ Theo

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 11:33:00 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Raphael Coeffic
> Sent: Thursday, March 05, 2009 4:48 AM
>
> The second difference is that it works

I think I know what you mean by this statement, but maybe I don't.  I think you mean it "works" right now only on a publicly reachable SIP provider that accepts INVITE requests from non-Registered Contacts.  No?  Or do you mean you've done testing of all publicly reachable SIP providers and found this to be an issue for all of them, right now?

Since the REGISTERs are almost always challenged, this attack is not an issue for providers which reject INVITEs from non-Registered Contacts.  Since SBC's have offered that restriction policy for at least the past 5 years, and presumably outbound-proxies do too (because it's a very popular policy), then you're really only talking about a theoretical subset of publicly reachable SIP Providers right now.

And this is not to say the attack isn't interesting, or that publicly reachable SIP providers actually *use* such security policies.  I've been surprised before about how some of them don't actually employ the security mechanisms they have at their disposal.  But not using available mechanisms is very different from not having a way to do them.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 11:44:11 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Theo
> Zourzouvillys
> Sent: Thursday, March 05, 2009 9:31 AM
>
> address in it.  ...  The second way is

Ummm... in what way?  The SBC *is* the outbound proxy.  And figure-3 isn't possible since clearly SBC's remove Alice's Via and Contact URI's, such that Bob won't know how to bypass the SBC to reach Alice.  And if the SBC doesn't do that, then you're right it's broken, and technically not an SBC but more like a 3GPP P-CSCF.  (And I heave heard some "SBC's" are really inline as ALG's, but the ALG model is known to be broken in real-world SIP use)

-hadriel

---

From: Theo Zourzouvillys <[email-masked]>
Date: Thu, 5 Mar 2009 16:49:26 +0000

On Thu, Mar 5, 2009 at 4:44 PM, Hadriel Kaplan <[email-masked]> wrote:

> And if the SBC doesn't do that,
> then you're right it's broken, and technically not an SBC but more like a 3GPP P-CSCF.  (And I heave heard some "SBC's" are really inline as ALG's, but the ALG model is known to be broken in real-world SIP use)

Indeed this is what i was referring too - although i'm sure there are
other types that are just as broken, not *all* vendors make SBCs that
work well.

if only we had a name for our rhinos, giraffes and gazelle, then we'd
be able to call them by their names, rather than just "aniamls".

:-)

 ~ Theo

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 06 Mar 2009 14:41:59 -0500

> know that his proxy does not challenge in-dialog requests it could simply

Except that there are legitimate uses for challenging in-dialog
requests:  sipX uses it to allow a phone to transfer a caller to any
destination that the executing phone has permission to call.  The first
step of this process is that when the executing phone sends a REFER, the
proxy challenges the REFER so that the executing phone attaches its
credentials to the REFER.  The proxy then analyzes these credentials to
determine the user that is responsible for the transfer operation, etc.
Without the in-dialog challenge, there is no way for the proxy to
determine the user that is responsible for transfer operation.

Dale

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 06 Mar 2009 23:21:21 +0100

> determine the user that is responsible for transfer operation.

Good point. Except that a REFER is not relevant for this replay attack. 
So would re-phrase it: I do not see a big benefit in challeging 
in-dialog INVITE requests. :-)

Greetings
   Nils

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 6 Mar 2009 22:29:32 +0000

On Fri, Mar 6, 2009 at 10:21 PM, Nils Ohlmeier <[email-masked]> wrote:

> Except that a REFER is not relevant for this replay attack

an authenticated OOD REFER may be used to initiate a call with some SIP devices.

 ~ Theo

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 06 Mar 2009 23:52:11 +0100

Am 06.03.2009 23:29 Uhr, schrieb Theo Zourzouvillys:
> On Fri, Mar 6, 2009 at 10:21 PM, Nils Ohlmeier<[email-masked]>  wrote:
>

Sure, but that is totally different story (of another bad UA 
implementation) which is not related to this auth relay attack.

   Nils

---

From: Jan Janak <[email-masked]>
Date: Sat, 7 Mar 2009 19:33:13 +0100

Nils,

On 05-03 14:40, Nils Ohlmeier wrote:
> attack: the proxies has to challenge in-dialog requests. 

It is not the proxy who challenges the in-dialog request, it is the
attacker (Bob). 

Even if the proxy is configured not to challenge in-dialog requests, or even
if digest authentication is not used at all on the proxy, as long as it
forwards the 407 from the attacker, the attack would still be possible. The
proxy (in figure 2) is only used to make sure that the 407 generated by Bob
makes it to Alice.

See figure 2 in the I-D, the 407 is generated by Bob based on the 407 he
received from p2.com. And the 407 from p2.com is a response to an
out-of-dialog INVITE.

So a requirement to make the attack possible is that the user agent responds
to challenges generated for in-dialog requests.

> I do not see a
> rejected by the remote side if no matching dialog exists. 

Yes, hopefully :-). But what if not? What if you deploy a poorly implemented
PSTN gateway which would happily process an in-dialog request with no matching
dialog?  Of course you can test the gateway before you deploy it if it is
under your control.

There are other cases where you know nothing about the target UA
implementation, such as when the users of your proxy call other users and you
have no control over the UA implementation they use. 

> request from a foreign domain. 

Because this is how it is specified in section 22.3 of RFC3261.

> In which scenario do I have credentials for

One such scenario is that you have a UA configured with credentials for two
different ITSPs and the UA uses another proxy server as the outbound proxy for
both of them. This outbound proxy could be your corporate proxy sitting on a
firewall, NAT conditioning proxy, SBC, etc..

   Jan.

---

From: Jan Janak <[email-masked]>
Date: Sat, 7 Mar 2009 20:09:22 +0100

> rather than shoddy implementations and insecure proxies.

Yes, after reading the discussion here I agree, perhaps the next revision of
the ID (if there is going to be any) should describe more difficult cases,
such as multi-hop authentication and challenging proxies reachable through one
common proxy. These are much harder cases to deal with.

   Jan.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 14:18:43 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jan
> Janak
> Sent: Saturday, March 07, 2009 1:33 PM
>

Right, and that the attacked domain accepts INVITEs from its AoR's with non-registered Contacts; or accepts INVITEs from its static AoR's to come in from unknown locations.  That's pretty rare in my world, but ymmv.

> dialog?  Of course you can test the gateway before you deploy it if it is

At that point you're describing something that is fundamentally broken.  All bets are off, including any preventative security measures you could take, etc.  I mean at that point you could just say "what if the user/password is published on a web site?"

> have no control over the UA implementation they use.

Then get yourself a box that enforces the protocol rules in the middle. :)

> Because this is how it is specified in section 22.3 of RFC3261.

And it would have to continue to do so.  There are actual use-cases for this.  I think there's even a reasonable use-case for challenging in-dialog requests: connected-identity, for example.

But you don't even need to challenge in-dialog requests for this form of attack: if the victim calls you, then you can challenge the initial INVITE.

-hadriel

---

From: Jan Janak <[email-masked]>
Date: Sat, 7 Mar 2009 20:50:45 +0100

> I think I know what you mean by this statement, but maybe I don't.  I think you mean it "works" right now only on a publicly reachable SIP provider that accepts INVITE requests from non-Registered…

I am not sure I understand how accepting/not-accepting INVITEs from
non-registered contacts makes it different, could you elaborate?

Roughly, as long as the attacker can establish a call with the victim and make
him/her respond to 407 within the session (for example by forcing the UA to
generate a re-INVITE), the attacker can get access to the victims
credentials. 

In some cases (if the victim UA is only reachable through a proxy
and the proxy removes its own credentials), the attacker would not be able to
get the credentials for that proxy, but might be able to get credentials for
another domain if the victim's UA is configured with multiple sets of
credentials.

I don't want to put words in Raphael's mouth, but he probably mentioned
publicly reachable SIP providers because they typically place no restrictions
on incoming calls for their users and thus this kind of attack can be easily
tried with them.

> And this is not to say the attack isn't interesting, or that publicly
> reachable SIP providers actually *use* such security policies.  I've been
> surprised before about how some of them don't actually employ the security
> mechanisms they have at their disposal.  But not using available mechanisms
> is very different from not having a way to do them.

Yes, I agree, in this case it would be interesting to know how many of them
actually remove used digest credentials before they forward SIP requests.

  Jan.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 14:51:54 -0500

Another question is whether an attacker can create special nonce's for one or more challenges it sends, that will help it figure out the password.  For example can they help a rainbow-table type of password cracking, and how much the cnonce can prevent that.

-hadriel

> Sent: Saturday, March 07, 2009 2:09 PM
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 15:45:57 -0500

> From: Jan Janak [mailto:[email-masked]]
> Sent: Saturday, March 07, 2009 2:51 PM
>

Assume Bob is bad, Alice is the victim.
The setup for the attack is such that Bob sends an INVITE to/through Alice's domain, pretending to be Alice.  Alice's domain challenges the INVITE, which Bob passes on to Alice, and using her challenge-response Bob challenge-responds to Alice's domain.  Right?

I am arguing that in common practice (in my particular market space, anyway), Alice's domain wouldn't accept Bob's spoofed INVITE to begin with.  Because it requires Bob's UA to actually be Registered as Alice in order to send in an INVITE pretending to be Alice.  Since REGISTER requests are challenged, and the digest-challenge mechanism includes the Method name in the calculation, Bob can't try to REGISTER into Alice's domain and use a challenge-response from her INVITE to do so.  Ergo, no problem.

Even for cases where they accept INVITE's from non-registering UA's (e.g, big IP-PBX SIP Trunks), my particular customer types often restrict what AoR can be claimed or allowed to make calls in from that trunk.

On the peering side, it's a different story - but the model they currently employ is a chain-of-trust, so they trust the peer to authenticate and control things in a similar fashion.  Whether that's a good idea or not is a different story, but that's the current model.  There are protection mechanisms available to prevent or at least mitigate this particular issue for peering, but I have less confidence that people use them in practice.

> on incoming calls for their users and thus this kind of attack can be

Not in my experience.  They place *many* restrictions on incoming calls.  But then those are my customers, which are just a subset, and obviously my view is undoubtedly myopic because those are the types of providers that would be talking to me to begin with.  And again, whether they actually use the tools at hand I don't know.

-hadriel

---

From: Victor Pascual Ávila <[email-masked]>
Date: Sat, 7 Mar 2009 22:15:27 +0100

On Sat, Mar 7, 2009 at 9:45 PM, Hadriel Kaplan <[email-masked]> wrote:
> I am arguing that in common practice (in my particular market space, anyway), Alice's domain wouldn't accept Bob's spoofed INVITE to begin with.  Because it requires Bob's UA to actually be Registered as Alice in order to send in an INVITE pretending to be Alice.

As an example: what would proxy.com check upon receipt of Bob's
spoofed INVITE over UDP (forging packet source ip and port)?

Thanks!
-- 
Victor Pascual Ávila

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sat, 7 Mar 2009 21:26:09 +0000

On Sat, Mar 7, 2009 at 8:45 PM, Hadriel Kaplan <[email-masked]> wrote:

> Not in my experience.  They place *many* restrictions on incoming calls.

>From what i see (at least in the UK), it seems to depend on if the
provider is selling "PSTN termination" or "SIP services".  The former
tend to place many restrictions (make calls only if registered and
from the IP that registered, only allow a single binding in AOR, etc),
and the later tend not to (although may provide customers with the
ability to).  In the UK, I'm seeing a slow shift from the former to
the later, although no idea about the rest of the world.

hmm, the above paragraph could almost have been talking about
AOL/compuserv vs a "real" ISP 15 years ago :-)

 ~ Theo

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 17:02:32 -0500

> From: Victor Pascual Ávila [mailto:[email-masked]]
> Sent: Saturday, March 07, 2009 4:15 PM
>

Well that is a trade secret, and specific to the proxy/SBC vendor being used, and probably its configuration. :)

But anyway if Bob could guess Alice's source UDP IP and port (which by the way is not always trivial to do), then it changes the form and scope of the attack.  The interesting characteristics of a relay-attack, baiting-attack, etc., are that they do not require IP-layer spoofing.

Typically, though, spoofing enough to get through would be less useful for Bob to do unless he's actually a true MitM, because the SIP responses for the call will go to Alice, so Bob won't be able to pass along the challenge and won't be able to establish a call.  And even if Alice's UA is broken enough to answer a challenge for a request it didn't send, Bob would not get the SIP responses to setup the call fully, nor send or receive media for it.  Bob could try to mount a resource-exhaustion attack on the provider, but that too is throttled (and besides Bob won't be able to get Alice to challenge-response fast enough for each INVITE).  Bob could try to perform an annoyance attack by making phones ring, if he figures out how to avoid getting Alice blocked automatically, but there are even countermeasures for that available.  Bob could try an attack for the purpose of getting Alice blocked from getting service for a period of time, but if Bob knows Alice's UDP source info he can do that directly on Alice anyway, and the best the provider can do is stop it from affecting others.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 17:39:59 -0500

> From: Theo Zourzouvillys [mailto:[email-masked]]
> Sent: Saturday, March 07, 2009 4:26 PM
>

Indeed. :)
And email has been getting less spam and phishing and viruses ever since.  And email has an even stronger architecture for security than SIP in some ways, ironically.  And less impact on the user-experience when it fails.  In many ways SIP's user-experience model is closer to IM than email, but with some worse security properties.  (and it's debatable if one would call IM "open", or end-to-end)

But even in that context of closed vs. open, you find web hosts having to employ strong and stronger means of user authentication, such as captcha's, and connection-layer security, such as TLS.  If the open SIP providers don't employ some counter-measures for spoofing, user authentication, and service control, then they will when the issues crop up. (if they have enough users to make attacking them interesting, which is the big "if")

But anyway, that's why I want a SIP Identity mechanism that actually works, fwiw.

-hadriel

---

From: Nils Ohlmeier <[email-masked]>
Date: Sat, 07 Mar 2009 23:40:50 +0100

> Right, and that the attacked domain accepts INVITEs from its AoR's with non-registered Contacts; or accepts INVITEs from its static AoR's to come in from unknown locations.  That's pretty rare in m…

Luckily it seems we are not living in the same world :-)
I call it a feature that I can make authenticated calls without being 
registered.

[...]

> And it would have to continue to do so.  There are actual use-cases for this.

Could you please share one of these use-cases with me.

> I think there's even a reasonable use-case for challenging in-dialog requests: connected-identity, for example.
>

Sorry, but how is this going to work in world without a SBC which knows 
my credentials?
Remember my proxy can not answer the challenge (CSeq mis-match). And the 
caller hopefully does not know my credentials, otherwise the whole 
attack would be pointless.

Cheers
   Nils

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sat, 7 Mar 2009 23:23:25 +0000

On Sat, Mar 7, 2009 at 10:39 PM, Hadriel Kaplan <[email-masked]> wrote:

> And email has been getting less spam and phishing and viruses ever since.

SIP also has one major advantage than email does: we've not *yet* got
the same penetration that SMTP did when it started really suffering.
Although I do see exactly the same apathy to the problem in voice
service providers and network operators now that I did in ISPs 10
years ago: "not a problem yet, can't afford to spend time on that".

> If the open SIP providers don't employ some counter-measures for spoofing, user authentication, and service control, then they will when the issues crop up.

It's difficult to do *that* much: a lot of the counter-measures need
support from the endpoint vendors for various features.  A look at the
quality (or even existence) of mutual TLS and related things in almost
all UAs speaks loads on their interest in such matters!

> But anyway, that's why I want a SIP Identity mechanism that actually works, fwiw.

i'll give 10 pounds (of the Great British variety) and a bottle of
sheppy's finest Somerset cider to whoever comes up with such a thing.

 ~ Theo

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 19:30:30 -0500

> From: Nils Ohlmeier [mailto:[email-masked]]
> Sent: Saturday, March 07, 2009 5:41 PM
>
> > Right, and that the attacked domain accepts INVITEs from its AoR's with
> non-registered Contacts; or accepts INVITEs from its static AoR's to come
> in from unknown locations.  That's pretty rare in my world, but ymmv.
>

Why, is sending a REGISTER hard??  It looks like a simple enough message to generate.  How about OPTIONS?
(has anyone ever noticed that OPTIONS is an anagram for POTIONS, or "O, NOT SIP" or "ON TO SIP" or "TON-O-SIP" or "TIS NO-OP" or "I NO POTS"? weird)

But anyway, sure - I'm not saying the attack isn't interesting or worth figuring out a solution/prevention for.  I think it *is*.  I was only challenging a claim that Service Providers on the Internet are currently exposed to it.  Not all of them are.

> Could you please share one of these use-cases with me.

Well, the 3GPP roaming case, for one.
A pictorial version: http://www.tech-invite.com/Ti-ims-regflow-1.html

> > I think there's even a reasonable use-case for challenging in-dialog
> requests: connected-identity, for example.
> >
> > But you don't even need to challenge in-dialog requests for this form of
> attack: if the victim calls you, then you can challenge the initial
> INVITE.
>

SBC's don't usually know your credentials, even now.  They don't need to.

But anyway, I'm not sure what you mean by the question.  How is what going to work?  Stopping INVITE-based authentication relay-attacks?  You don't need an SBC-type box to stop that.  Just disconnect the cable.  :)
Or, use the counter-measures in the draft.  Or change the protocol, or at least the authentication mechanism.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 23:25:20 -0500

> Hadriel Kaplan
> Sent: Saturday, March 07, 2009 7:31 PM
>
> But anyway, I'm not sure what you mean by the question.  How is what going
> to work?  Stopping INVITE-based authentication relay-attacks?  You don't
> need an SBC-type box to stop that.  Just disconnect the cable.  :)

BTW, you don't need to be an SBC to have such policies.  There is nothing in RFC 3261 which prohibits a pure Proxy from restricting who it accepts INVITEs from, and when.  There are even some clever tricks one can do to make it a stateless mechanism.

-hadriel

---

From: Raphael Coeffic <[email-masked]>
Date: Mon, 09 Mar 2009 12:41:33 +0100

> BTW, you don't need to be an SBC to have such policies.  There is nothing in RFC 3261 which prohibits a pure Proxy from restricting who it accepts INVITEs from, and when.  There are even some cleve…
That's a good point. Requiring the user to be registered and only 
accepting requests from the registered contacts provide a fair-enough 
level of security concerning the attack debated. But I am still hoping 
that we could find a solution not requiring this kind of measures, which 
I would call "user-restricting".

-Raphael.

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Mon, 9 Mar 2009 16:04:41 +0100 (CET)

>> > And it would have to continue to do so.  There are actual use-cases
>> for
>> this.
>>

Well you are right, I was just thinking about the "typical"
proxy/registrar combination. But there are outbound or travesering
proxyies which don't do authentication at all.

To stay at your 3GPP romain case: I don't think this attack would be
possible if the S-CSCF does not pass through "unknown" auth requests.
Right?

The P-CSCF has to forward REGISTERs to non-local S-CSCF which then will
authenticate the registration with "unknown"/non-local realms. But as soon
as the UA is registered the P-CSCF should only accept terminating INVITE
requests for that UA from the S-CSCF where the user is registered to. And
again the S-CSCF of the user/UA has in my opinion no need to forward
"foreign" authentication requests, or?!

BTW as you pointed out already earlier debating this attack for IMS is
only hypothetical, because IMS allows calls only from registered UAs.

And from a more general perspective:
I believe that such a transitive proxy which does not do authentication by
himself should only accept auth requests from the serving/registrar proxy
(or however you call the element which does the authentication part).
Furthermore this transitive proxy should not allow dialogs over "just
transitive proxys" (which have now clue about authentication) only
(because that would allow the attacker again to send a challenge).

> least the authentication mechanism.

My fault. I mis-read your original point.

Cheers
  Nils

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 9 Mar 2009 16:30:01 -0400

> From: Raphael Coeffic [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 7:42 AM
>

How is it "user-restricting" to require a UA to generate a REGISTER request?  Most humans don't generate the REGISTER request by hand - typically software does it for them.  :)
I mean at that point you can also just say "digest authentication is user-restricting".

-hadriel

---

From: Raphael Coeffic <[email-masked]>
Date: Tue, 10 Mar 2009 11:06:23 +0100

> How is it "user-restricting" to require a UA to generate a REGISTER request?  Most humans don't generate the REGISTER request by hand - typically software does it for them.  :)

Forcing registrations is the path that IMS went for, I believe. But if 
you want to take advantage of this, you may have to deploy a little more 
IMS than you'd like to. This reminds me of some email providers that 
require you to connect through POP3 prior to send any message through 
SMTP, instead of deploying any secure authentication mechnism.

Maybe just an example: let's say you have a home SIP server, doing the 
usual least cost routing. Your least cost router might have something 
like 50 different routes. Do you want this box, or maybe your phones to 
have 50 running registrations, just for the purpose of having cheap 
calls? Well, personaly, I would prefer to just install my certificate on 
this box, and use TLS. But as very very few of those PSTN providers do 
support TLS, I cannot. By the way, there are already commercial products 
supporting this scenario.

Regards,
Raphael.

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 10 Mar 2009 14:02:34 -0400

On Sat, 2009-03-07 at 14:51 -0500, Hadriel Kaplan wrote:

> Another question is whether an attacker can create special nonce's for
> one or more challenges it sends, that will help it figure out the
> password.  For example can they help a rainbow-table type of password
> cracking, and how much the cnonce can prevent that.

If the cnonce is well chosen and the nc value incremented, I think that
gets pretty hard, but I'm not by any means an expert on cracking one-way
hash functions.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Mar 2009 17:36:24 -0400

> Sent: Tuesday, March 10, 2009 6:06 AM
> 
> Hadriel Kaplan wrote:
> 
> IMS than you'd like to. 

The concept and practice of "forcing" UA's, which have AoR's belonging to a domain, to REGISTER their contact binding for those AoR's in order to make calls, has been around a lot longer than IMS has.  Invoking the "that sounds like IMS" defense is a cheap guilt-by-association argument, and not relevant.  One might as well argue that using INVITE's or RTP "is the path that IMS went for".

You keep making it sound like sending a SIP request which does not create a dialog is somehow a difficult mechanism to implement, or "forces" people to do something they don't want to.  What is it forcing?

You're looking for a means of authenticating a UA without being subject to a relay attack.  Using a different SIP Method name, which can only be initiated by the client with the credentials, and one that UA's cannot be baited to provide by random third parties, is one solution to the problem.  If you don't like the string "REGISTER", then how about "OPTIONS"?

> This reminds me of some email providers that

No, this is more like a Website which offers email services requiring you to login using your credentials before letting you send.  It's not analogous to making you use POP3 because a REGISTER does not use a different protocol, and can be tied to the same connection-layer "flow" as the INVITE et al.

You may not like it, but any form of authentication by definition is more restrictive than no form of authentication.

> supporting this scenario.

So you have a mechanism that people don't seem to want to implement - and meanwhile you have another mechanism, which is widely implemented.  And the problem is...?

-hadriel

---

From: Raphael Coeffic <[email-masked]>
Date: Wed, 11 Mar 2009 09:52:59 +0100

> You keep making it sound like sending a SIP request which does not create a dialog is somehow a difficult mechanism to implement, or "forces" people to do something they don't want to.  What is it…
Well, it is not required as per RFC 3261 ;-)

> You're looking for a means of authenticating a UA without being subject to a relay attack.  Using a different SIP Method name, which can only be initiated by the client with the credentials, and on…
No, I think you missunderstood me. I still think that requiring a 
registration and checking the source IP and port against the registered 
contact is a fair measure to take. However, it introduces more traffic 
in some scenarios, where it is not necessarily needed. REGISTERs could 
become the "background load" in the servers. This also puts a lot of 
state into some proxies that does not need it, etc...
My concern is just that it seems like there is no better solution.
> So you have a mechanism that people don't seem to want to implement - and meanwhile you have another mechanism, which is widely implemented.  And the problem is...?
See previous answer.

Cheers
Raphael.

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Wed, 11 Mar 2009 14:49:50 +0100 (CET)

>> The concept and practice of "forcing" UA's, which have AoR's belonging
>> to a domain, to REGISTER their contact binding for those AoR's in order
>> to make calls, has been around a lot longer than IMS has.  Invoking the
>> "that sounds like IMS" defense is a cheap guilt-by-association argument,
>> and not relevant.  One might as well argue that using INVITE's or RTP
>> "is the path that IMS went for".
>>
>> You keep making it sound like sending a SIP request which does not
>> create a dialog is somehow a difficult mechanism to implement, or
>> "forces" people to do something they don't want to.  What is it forcing?
>>
>>
>> You're looking for a means of authenticating a UA without being subject
>> to a relay attack.  Using a different SIP Method name, which can only be
>> initiated by the client with the credentials, and one that UA's cannot
>> be baited to provide by random third parties, is one solution to the
>> problem.  If you don't like the string "REGISTER", then how about
>> "OPTIONS"?
>>
>>

Sure to create a Contact binding via an authenticated REGISTER is one
possible solution.
But I think this only works because you rely on the fact that REGISTERs
are not being retargeted like INVITEs. Which then in the end means you
simply can forget about authenticating all other requests, as long as the
Contact or IP/port was successfully authenticated via the "one hop"
REGISTER method (refer-to: IMS).
The advantage of this solution is clearly that it can be easily deployed
by hopefully most of the service providers today.

But I believe the proper technical solution would be that the server
authenticates itself in the challenge, plus adding protected informations
to the challenge which allows the receiver of the challenge to verify that
this challenge was/is targeted to himself.
The dis-advantage is clearly that this would be only possible with
extensions of the existing protocols. But we would/might gain other
benefits by such a solution as well.

Regards
  Nils Ohlmeier

---

From: Victor Pascual Ávila <[email-masked]>
Date: Thu, 12 Mar 2009 17:59:16 +0100

> benefits by such a solution as well.

I did not follow the discussion on draft-dotson-sip-mutual-auth. Has
this work been discontinued?

http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt

Cheers,
-- 
Victor Pascual Ávila

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Thu, 12 Mar 2009 19:39:13 +0100 (CET)

> http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt

I can not answer your question.

But this draft does not solve the discussed attack, because the server is
authenticated after the victim sends its credentials to the attacker
alerady. To have a chance to solve the attack scenario the
server/challenger would have to prove its identity together with the
challenge to prevent that the victim sends out its credentials to the
attacker at all.

Regards
  Nils Ohlmeier

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 14 Mar 2009 08:26:36 -0400

Rafael and others,

Thanks for putting this together.

Considering for a moment figure 1, this attack is possible only if UAs 
accept incoming requests from any place, and not just their proxy. In 
practice, this is seldom allowed. Indeed, if it is allowed, there are 
worse attacks than this which can be launched (free phone calls, spam 
calling, etc.). Using the SIP recommended TLS between UA and proxy also 
mitigates that.

So really figure 2 is the interesting one. However, this attack assumes 
that Alice has credentials on multiple systems. Again, in practice, this 
is extremely uncommon. Certainly none of the existing deployed 
enterprise or service provider consumer deployments are of this nature.

As such, I dont think this attack is likely in practice. However, in 
theory it is possible. The essence of the attack is that the victim is 
providing credentials to an unauthenticated server (since the attacker 
is acting like a server, asking for credentials). In that way, as others 
have pointed out, it is similar to baiting attacks that have been 
previously documented. With SIP it is most easily remedied by a rule 
which says, 'don't pass credentials for domain X to a server that is not 
domain X'. Server identity can be verified by normal server-only auth 
between a client and its server, but even that is not needed. A client 
will know which domain its proxy is representing, and once connected, it 
only provides credentials for that domain.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Raphael Coeffic <[email-masked]>
Date: Mon, 16 Mar 2009 10:46:23 +0100

Jonathan Rosenberg wrote:
> Raphael and others,
> calling, etc.). Using the SIP recommended TLS between UA and proxy 
> also mitigates that.
>
That's right, and also the reason we called this the basic attack. Using 
TLS would be indeed a good choice, unfortunately, only few providers do 
offer it to their customers (but of course, only for the small panel I 
know of, and those I use).

> So really figure 2 is the interesting one. However, this attack 
> assumes that Alice has credentials on multiple systems. Again, in 
> practice, this is extremely uncommon. Certainly none of the existing 
> deployed enterprise or service provider consumer deployments are of 
> this nature.
I understand that this might not be a common case, as the common case is 
more focused on a vonage (or alike) customer, receiving a 
ready-configured phone that just has to be pluged into the residential 
gateway. However, a lot of SIP freaks like us do have a lot of 
configured accounts on the same phone, and not only for test purposes. 
For my part, my home phone is connected with 3 accounts: one default 
(PSTN), my iptel.org account, and another provider that own one of our 
PSTN numbers (only inbound).

I have seen one year ago an application for a residential gateway 
implementing a SIP least cost router. It was available as an unofficial 
upgrade for a very popular type of resential gateway. In the case, the 
configuration was at its minimum: all the required config was downloaded 
by the least cost router application. All you had to do was to create 
some accounts at some PSTN provider, and configure them into the box, 
which would do the rest.

I can believe that this kind of application could become more popular, 
just like they were in the PSTN.

> is acting like a server, asking for credentials). In that way, as 
> others have pointed out, it is similar to baiting attacks that have 
> been previously documented. With SIP it is most easily remedied by a 
> rule which says, 'don't pass credentials for domain X to a server that 
> is not domain X'.
Which means that you exclude any relays in between. I think it also 
implies reverse DNS lookups, right?

> Server identity can be verified by normal server-only auth between a 
> client and its server, but even that is not needed. 
Right, mutual authentication seems to be the best way.

> A client will know which domain its proxy is representing, and once 
> connected, it only provides credentials for that domain.
>
What do you mean by "connected"? And why should a UA only provide 
credentials for one domain only?
Is that about TCP or SCTP connections? and providing only credentials 
for a particular domain on a particular connection?

-Raphael.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Mar 2009 16:46:04 -0400

> implies reverse DNS lookups, right?

No - no reverse DNS.
And I am excluding cases where, you are connected (meaning, the domain 
you registered to) to one domain and making a call through that domain 
reach another domain which requires your credentials. I think that is 
very unlikely.

> credentials for one domain only?

I'm saying, when a phone registers or makes a call, it does so by 
connecting to a SIP server, through a domain name or IP config or 
whatever. THat server will have an associated credential. For any 
request sent to that server, it should never provide a credential except 
the one associated with it.

Your attack is possible only when the client sends credentials for a 
domain, different than the one it is currently registered or placed the 
call through in the first place.

-Jonathan R.

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 16 Mar 2009 23:00:57 +0100

> call through in the first place.

And the SIP server which relays the INVITE from the attacker to the 
victim has to drop (?) the challenge if it receives such from the 
attacker (at least if the realm is identical to the one used by the 
server itself).

This is basically the same description which I provided already earlier.

The only open "issue" is then relaying of 407/401 replies from 
downstream elements by the proxy. I agree with Jonathan that I also do 
not believe that this actually a real world scenario. But mutual 
authentication in the challenge might help to solve this issue if people 
insist of keeping this scenario.

Regards
   Nils

---

From: Raphael Coeffic <[email-masked]>
Date: Tue, 17 Mar 2009 10:48:55 +0100

Nils, Jonathan,

You may be aware of it or not, however, we have already implemented this 
scenario at iptel.org. This is because iptel.org does not have any own 
PSTN gateway. In this case, the user can configure a PSTN gateway he 
whishes to use when such a number is dialed. We implemented like this to 
cope with all the low-end phones that do not provide multiple accounts, 
or do not offer a convenient way for the user to provide routing rules.

Even cisco and snom phones (at least those we have) are not able to 
select the outbound account on their own, based on the R-URI. On the 
other hand, this is very easy to offer at the proxy level, provided that 
my proxy does relay challenges and responses to the UA (in this case, 
the realm is different).

So, as a conclusion, I do not think we are talking about theory, but 
about real existing applications. Of course, you could also store your 
other PSTN credentials at the proxy, and make it deal with the 
authentication for you. However, I'm quite sure you wouldn't be very 
confident about that, would you?

Regards,
Raphael.

Nils Ohlmeier wrote:
> authentication in the challenge might help to solve this issue if 
> people insist of keeping this scenario.
>
> Regards
>   Nils

---

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 17 Mar 2009 11:17:35 +0100

On Tue, Mar 17, 2009 at 10:48 AM, Raphael Coeffic <[email-masked]> wrote:
> scenario at iptel.org. This is because iptel.org does not have any own PSTN
> gateway. In this case, the user can configure a PSTN gateway he whishes to
> use when such a number is dialed. We implemented like this to cope with all
> the low-end phones that do not provide multiple accounts, or do not offer a
> convenient way for the user to provide routing rules.

I agree-- some terminating domains may require authentication. Indeed,
this is defined in rfc3665 as a BCP. In Section 3.3 (Session with
Multiple Proxy Authentication), Proxy 1 is relaying challenges and
responses for different (sub)domains.

> So, as a conclusion, I do not think we are talking about theory, but about
> real existing applications. Of course, you could also store your other PSTN
> credentials at the proxy, and make it deal with the authentication for you.
> However, I'm quite sure you wouldn't be very confident about that, would
> you?

Once again, IMHO this should be as much end-to-end as possible. Some
folks are still using SIP as a protocol for the (open) Internet.

Cheers,
-- 
Victor Pascual Ávila

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 25 Mar 2009 15:04:32 +0100

Jonathan Rosenberg wrote:
> practice, this is seldom allowed. 

Hi Jonathan,
I see two things with this argument: first being a practical, the
other normative. on contrary to what you have observed, in the SIP
deployments I'm aware of the SIP UA accept SIP from everywhere.
That I consider a poor practice, but it seems to be the case.
(perhaps a differnet market segment experience?)
It has been also utilized in the DE attack last year -- attacker
sent SIP packets directly to UAs.
www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf
I should be in position to do a live measurement of a quite
SIP-UA-wise heterogenous SIP service, should we need more accurate
field intelligence.

The normative argument is that a SIP UA must be prepared to receive
traffic for a dialog setup by an RFC3261 proxy, which has no
obligation to record-route, and the traffic can therefore come
from anywhere. Unless we standardize that the UAs
are behind NATs, deprecate record-routing as optional or more
seriously document BCPs (don't talk with strangers), a SIP-compliant
UA is an open invitation for unsolicited traffic.

I'm under impression that folks in this threads feel easy about
the problem because they have all sorts of workarounds -- these
however do not rely on any sort of normative reference and seem
thus rather brittle.

Possibly addressing some of these practices in a BCP could
help to sort out some of that. Actually some ITSPs I know have been
privately approaching their UA vendors and felt they have never
made progress because there was no reference for such behaviour.

-jiri

> Indeed, if it is allowed, there are