Re: [Sip] draft-state-sip-relay-attack-00
Jiri Kuthan <jiri@iptel.org> Wed, 25 March 2009 14:03 UTC
Return-Path: <jiri@iptel.org>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B693A69F9 for <sip@core3.amsl.com>; Wed, 25 Mar 2009 07:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.447
X-Spam-Level:
X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, GB_I_INVITATION=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arp4nu5ZMJJC for <sip@core3.amsl.com>; Wed, 25 Mar 2009 07:03:44 -0700 (PDT)
Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id DD5783A693E for <sip@ietf.org>; Wed, 25 Mar 2009 07:03:43 -0700 (PDT)
Received: from dhcp-46c3.meeting.ietf.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0EDB21811CD5; Wed, 25 Mar 2009 15:04:32 +0100 (CET)
Message-ID: <49CA39F0.1010303@iptel.org>
Date: Wed, 25 Mar 2009 15:04:32 +0100
From: Jiri Kuthan <jiri@iptel.org>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com>
In-Reply-To: <49BBA27C.4050805@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
Subject: Re: [Sip] draft-state-sip-relay-attack-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2009 14:03:45 -0000
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 sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Michael Procter
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Dan Wing
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Jan Janak
- Re: [Sip] draft-state-sip-relay-attack-00 Michael Procter
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Dan Wing
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Dale Worley
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Jan Janak
- Re: [Sip] draft-state-sip-relay-attack-00 Jan Janak
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Jan Janak
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Victor Pascual Ávila
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Theo Zourzouvillys
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Scott Lawrence
- Re: [Sip] draft-state-sip-relay-attack-00 Hadriel Kaplan
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Victor Pascual Ávila
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Jonathan Rosenberg
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Jonathan Rosenberg
- Re: [Sip] draft-state-sip-relay-attack-00 Nils Ohlmeier
- Re: [Sip] draft-state-sip-relay-attack-00 Raphael Coeffic
- Re: [Sip] draft-state-sip-relay-attack-00 Victor Pascual Ávila
- Re: [Sip] draft-state-sip-relay-attack-00 Jiri Kuthan