Subject: [Sipping] comments on draft-jung-sipping-authentication-spit-

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Oct 2006 18:27:07 -0400

Thanks for putting this together. SPIT/SPAM is an important problem 
looming ahead of us and I am glad to see work on it.

I agree that the potential for spam increases if a UA receives INVITE 
requests directly from the spammers without going throguh the proxy. 
This is particularly true if the network is providing servcies like 
black and whitelisting, turing tests, and other services.

However, I do not agree with the solution that is proposed.

Firstly, it is actually highly unlikely that such direct UA INVITEs are 
likely to work. If a firewall or NAT is present between the client and 
the network, and said firewall/NAT requires the UA to generate an 
outbound request to an IP/port before receiving packets back in (this 
would be an address restricted NAT, for example), then this would 
prohibit such an incoming call. THe only incoming calls would arrive 
through the proxy. Requests from arbitrary hosts on the Internet would 
be blocked.

Even a host firewall, running on the client itself (think Norton 
Internet Security) would achieve the same result.

Secondly, a far superior solution to digest (assuming you discount the 
effectiveness of firewalls...) is to use SIP/TLS to the outbound proxy. 
Your draft notes this solution but indicates that it is too complex. I 
would rather recommend the right tool for the right problem, and SIP 
over TLS is clearly better.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Oct 2006 16:58:31 -0700

Jonathan Rosenberg wrote:

> Firstly, it is actually highly unlikely that such direct UA 
> INVITEs are likely to work. If a firewall or NAT is present 
> between the client and the network, and said firewall/NAT 
> requires the UA to generate an outbound request to an IP/
> port before receiving packets back in (this would be an 
> address restricted NAT, for example), then this would 
> through the proxy. Requests from arbitrary hosts on the 
> Internet would be blocked.
>

That relies on the existance of a firewall, NAT, or host-based firewall, to
protect the host.  That's pretty lousy, security-wise.  In the IETF, none of
those technologies (NATs, host-based firewalls, or firewalls) "exist".  

The draft described the attack scenario:

   STEP 1. Collect SIP URI and IP address of victims. 
   STEP 2. Generate an INVITE message including IP address and port 
           number of spammer for RTP session in SDP. 
   STEP 3. Spoof the IP address of a inbound proxy server. 
   STEP 4. Send out the INVITE message directly to the UAS. 
   STEP 5. Sniff the 200 OK message. 
   STEP 6. Collect the IP address and port number from the 200 OK. 
   STEP 7. Establish communication channel with the UAS. 

Step (3) is viable (there are many networks which don't enforce reverse path
forwarding, BCPs 38 and 84).  To actually sniff the 200 OK you need to be
on-path.  However, I can imagine predictable media port numbers, or an
attacker willing and able to send their RTP stream to many port numbers,
would be successful without needing to actually sniff the 200 OK.

So, this attack is something I would consider 'real'.

> Secondly, a far superior solution to digest (assuming you 
> discount the effectiveness of firewalls...) is to use SIP/TLS 
> to the outbound proxy.  Your draft notes this solution but 
> indicates that it is too complex.  I would rather recommend the 
> right tool for the right problem, and SIP over TLS is clearly better.

I agree TLS would be better, and TLS is pretty easy in 2006.

However, even without TLS, I think RFC3261 already solved the same problem
that this document solves:

RFC3261 allows use of the Authentication-Info header, which I had understood
provided mutual authentication between the UAS and its proxy, using the
response-auth field of the Authentication-Info header (RFC2617, section
3.2.3).

The draft implies that Authentication-Info is unable to provide
authentication of messages from the proxy, but doesn't come outright and
explain how Authentication-Info fails at its intended purpose.  I assume the
authors found Authentication-Info deficient, but the deficiency isn't
described in the Internet Draft and I don't recall seeing a discussion on
the mailing list.

-d

---

From: 최재덕 <[email-masked]>
Date: Mon, 30 Oct 2006 22:16:52 +0900

Sorry for the late response to your comments.
Please see my comments in line.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 7:27 AM
To: IETF Sipping List
Subject: [Sipping] comments on draft-jung-sipping-authentication-spit-

===>
You are right. 
NAT is only a part of whole VoIP networks. The proposed spam attack,
therefore is still possible 
in normal VoIP networks without NAT.

===>
OK, I agree that SIP over TLS would be better in security aspects.
But, the usage of TLS is optional in UA, and many UA implementations do not
just support the TLS. 
Therefore, the spam threat is real, and we have found several commercial
UAs that are exposed to the spam attack.
The proposed digest scheme is much lighter than the TLS, so it is expected
to be easily equipped in the UA.

Thanks,
Jonathan R.

---

From: 최재덕 <[email-masked]>
Date: Mon, 30 Oct 2006 22:25:08 +0900

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Thursday, October 19, 2006 8:59 AM
To: 'IETF Sipping List'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; 'Jonathan Rosenberg'
Subject: RE: [Sipping] comments on draft-jung-sipping-authentication-spit-

========================>
I think that Authentication-Info solves the mutual authentication with 2xx
response between UA and registrar.
Also, it is possible to use between the UAC and the outbound proxy.
However, inbound proxy does not apply digest scheme when it forwards INVITE
messages to a UAS during session establishment.

          UAC                                   UAS(Registrar)
           |               REGISTER                      |
           |-------------------------------------->|
           |<----------401 (WWW-Authenticate)------|
           |-----------REGISTER(Authorization)---->|
           |<----------200 (Authentication-Info)---|

          UAC      Outbound Proxy   Inbound Proxy            UAS
           |                   |                   |                    | 
           |                   |   Call Flow     |                    | 
           |=================================================>| 
           |                   |                   |                    | 
           |     INVITE       |                   |                    | 
           |--------------->|                   |                    | 
           |                   |   INVITE         |                    | 
           |                   |--------------->|   INVITE          | 
           |                   |                   |--------------->| 
           |    Digest (O)   |                   |                    | 
           |                   |                   |    Digest (X)    | 
           |                   |                   |     ...           | 
           |                   |                   |     200           | 
           |                   |    200            |<---------------| 
           |200(Auth-Info.) |<---------------|                    | 
           |<---------------|                   |                     |

---

From: Hendrik Scholz <[email-masked]>
Date: Mon, 30 Oct 2006 16:51:45 +0100

Hi!

Dan Wing wrote:
> on-path.

There are scenarios where you don't have to sniff the 200 OK but simply 
rely on SIP routing.
An attacker could preload the INVITE from step 4 with 
Routing-Information (Record-Route, Route or even Service-Route) to make
the UAS send the 200 OK directly to the attacker thus punching a new
hole into the firewall. If that doesn't work one might add two headers
which route the answer from the UAS the the UAS's outbound proxy which
itself forwards the response on to the attacker.
Further communication would be directly between the attacker and UAS
or using the spoofed source address to implement the attacker -> UAS -> 
outbound proxy -> attacker loop.

Cheers,
  Hendrik

-- 
Hendrik Scholz - <[email-masked]> - http://www.wormulon.net/
drag me, drop me - treat me like an object

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 16:15:34 -0800

Thanks for your reply.

...
> messages to a UAS during session establishment.

Would it be sufficient for UAS and proxy to require the inbound proxy to
authenticate INVITE messages, using the Authentication-Info already
described in RFC3461, or is the mechanism described in your draft required?

-d

>            |                   |                   |          
>           | 
>            |                   |   Call Flow     |            
>         | 
>            |                   |                   |          
>           | 
>            |     INVITE       |                   |           
>          | 
>            |--------------->|                   |             
>        | 
>            |                   |   INVITE         |           
>          | 
>            |    Digest (O)   |                   |            
>         | 
>            |                   |                   |    
> Digest (X)    | 
>            |                   |                   |     ...  
>          | 
>            |                   |                   |     200  
>          | 
>            |<---------------|                   |             
>         |

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 16:17:50 -0800

> From: Hendrik Scholz [mailto:[email-masked]] 
> Sent: Monday, October 30, 2006 7:52 AM
> To: Dan Wing
> Cc: 'IETF Sipping List'; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Sipping] comments on 
> draft-jung-sipping-authentication-spit-
> 
> Hi!
> 
> Dan Wing wrote:
> or using the spoofed source address to implement the attacker 
> -> UAS -> outbound proxy -> attacker loop.

Requiring the (legitimate) proxy to authenticate all messages it
sends to the UAS, using Authentication-Info, seems to provide
protection from that attack.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Oct 2006 13:09:47 -0500

I still prefer to use an existing mechanism that provides a superior
solution to the problem, then specify a new one that is not as effective
(i.e., digest w/o has known vulnerabilities to dictionary attacks). We
are seeing more and more TCP/TLS being implemented.

-Jonathan R.