Re: [martini] #56: GRUU mechanism security review

"martini issue tracker" <trac@tools.ietf.org> Sat, 17 July 2010 15:09 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109D23A699E for <martini@core3.amsl.com>; Sat, 17 Jul 2010 08:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level:
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 SJwDxLDy0LcC for <martini@core3.amsl.com>; Sat, 17 Jul 2010 08:09:03 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BCCA93A699A for <martini@ietf.org>; Sat, 17 Jul 2010 08:09:02 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oa90r-0006zL-S5; Sat, 17 Jul 2010 08:09:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: martini issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: adam@nostrum.com, bernard_aboba@hotmail.com
X-Trac-Project: martini
Date: Sat, 17 Jul 2010 15:09:13 -0000
X-URL: http://tools.ietf.org/martini/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:3
Message-ID: <066.d9e1f362baf76b05905b70faa7324316@tools.ietf.org>
References: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org>
X-Trac-Ticket-ID: 56
In-Reply-To: <057.f315a40650bef16891c861df51826fc3@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: martini@ietf.org
Subject: Re: [martini] #56: GRUU mechanism security review
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jul 2010 15:09:06 -0000

#56: GRUU mechanism security review
-----------------------------+----------------------------------------------
 Reporter:  rbarnes@…        |        Owner:  adam@…          
     Type:  defect           |       Status:  closed          
 Priority:  major            |    Milestone:  milestone1      
Component:  gin              |      Version:  1.0             
 Severity:  In WG Last Call  |   Resolution:  fixed           
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 I can't for the life of me work out what attack I thought I was
 preventing here. You are correct that being able to mint valid cookies
 would allow one PBX to send out GRUUs that routed to another PBX, but
 that's hardly a useful attack. It could just as easily hand out normal
 URIs in its contact that route to another PBX -- or, for that matter,
 GRUUs that it had received from another PBX. And, with GRUUs, even if it
 could mint its own ones that route elsewhere, they wouldn't pass the
 final validation step at the targeted PBX anyway.

 So I don't think there's anything there we need to worry about.

 That said, protecting I with an HMAC may still have some value --
 although I can't construct an attack based on being able to generate
 these somewhere other than the SSP.

 I propose removing 2 and 3, as they're not desirable (as far as I can
 tell).

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/56#comment:3>
martini <http://tools.ietf.org/martini/>