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

Jonathan Rosenberg <jdrosen@cisco.com> Sat, 14 March 2009 12:26 UTC

Return-Path: <jdrosen@cisco.com>
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 8429B3A67E5 for <sip@core3.amsl.com>; Sat, 14 Mar 2009 05:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 URCiiIti3clF for <sip@core3.amsl.com>; Sat, 14 Mar 2009 05:26:01 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 88A8E3A6A48 for <sip@ietf.org>; Sat, 14 Mar 2009 05:26:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,362,1233532800"; d="scan'208";a="155804148"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Mar 2009 12:26:38 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2ECQcgU026470; Sat, 14 Mar 2009 05:26:38 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2ECQcTW019678; Sat, 14 Mar 2009 12:26:38 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Mar 2009 05:26:38 -0700
Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Mar 2009 05:26:37 -0700
Message-ID: <49BBA27C.4050805@cisco.com>
Date: Sat, 14 Mar 2009 08:26:36 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Raphael Coeffic <rco@iptel.org>
References: <49AE593F.6080807@iptel.org>
In-Reply-To: <49AE593F.6080807@iptel.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Mar 2009 12:26:38.0177 (UTC) FILETIME=[1F309510:01C9A4A0]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3846; t=1237033598; x=1237897598; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:=20Re=3A=20[Sip]=20draft-state-sip-relay-attack-00 |Sender:=20; bh=HXnpwoqbyHEeyu1/DB3NcG0Zw9iotm0TG+INQJs01Ac=; b=MQHWzOJyMCUjco769p5Rh5iKQwTDxL4NVtddjXenj6F8mwYugwxznSowbj fzcY62jdNCD+YuTcx1Zj0HUz9felJqz0GFr8ngDilYRMtQL6Mu8GCPbQMo6W CHA9x2kVxb;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
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: Sat, 14 Mar 2009 12:26:02 -0000

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.


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
> 

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