Re: draft-state-sip-relay-attack-00

Jonathan Rosenberg wrote:
> 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. 

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
> 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.
> 
> 
> Raphael Coeffic wrote:
>> 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.
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email protected] for questions on current sip
>> Use [email protected] for new developments on the application of sip
>>
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip