Re: [martini] #56: GRUU mechanism security review
"martini issue tracker" <trac@tools.ietf.org> Mon, 19 July 2010 12:39 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 D44123A6895 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 05:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level:
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 d4J-4z55bfTU for <martini@core3.amsl.com>; Mon, 19 Jul 2010 05:39:49 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F20883A67F4 for <martini@ietf.org>; Mon, 19 Jul 2010 05:39:48 -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 1OapdV-0005lA-8F; Mon, 19 Jul 2010 05:39:57 -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, henrik@levkowetz.com
X-Trac-Project: martini
Date: Mon, 19 Jul 2010 12:39:57 -0000
X-URL: http://tools.ietf.org/martini/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/56#comment:5
Message-ID: <066.fbe906d86880286d1f4c6b725e32ebc2@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, henrik@levkowetz.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: Mon, 19 Jul 2010 12:39:52 -0000
#56: GRUU mechanism security review -----------------------------+---------------------------------------------- Reporter: rbarnes@… | Owner: adam@… Type: defect | Status: reopened Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+---------------------------------------------- Old description: > Just took a look at the GIN GRUU construction. It looks correct to > me, and the split between required and optional seems sensible. My > summary of the algorithm is below, in case it's helpful. > > The security requirements 2 and 3 in 7.1.2.1 seem poorly specified (1, > 4, and 5 seem obvious enough). W.r.t. 2: It seems like the risk here > is that a PBX might be able to make GRUUs that route to another PBX, > which is the opposite of what this says. W.r.t. 3: The current > algorithm doesn't protect against this; it would need something > related to time. > > ===== KEYS ===== > > Key Type Known to > SK_SSP HMAC key SSP > pk_SSP Private key SSP > Pk_SSP Public key SSP, PBX > SK_PBX HMAC key PBX > > ===== GENERATION ===== > > SSP (general): > cookie = [ random; identifies PBX; fixed-length ] > > SSP (optional): > I = [ identifier for PBX ] > J = HMAC(SK_SSP, I) // Prevents spoofing cookies if I is known but > not SK_SSP > cookie = I || J > > SSP -> PBX: > cookie > > PBX: > D = [ per-temp-GRUU random ] > M = cookie || D > E = RSA_Encrypt(Pk_SSP, M) > PA = HMAC(SK_PBX, E) > > PBX -> UA: > temp-gruu = [ E, PA ] > > ===== VALIDATION ===== > > UA' -> SSP: > temp-gruu = [ E, PA ] > > SSP (general): > M' = RSA_Decrypt(pk_SSP, E) > cookie' = [ truncated M' ] > cookie-valid = [ proprietary ] > > SSP(optional) > M' = RSA_Decrypt(pk_SSP, E) > cookie' = [ truncated M' ] > I', J' = [ split cookie' ] > cookie-valid = (J' == HMAC(SK_SSP, I')); > > SSP (general): > if (cookie-valid) > generated by SSP for PBX identified by I' > > SSP -> PBX: > temp-gruu' = [ E, PA ] > > PBX: > if (PA == HMAC(SK_PBX, E)) > generated by PBX for UA identified by 'gr' New description: Just took a look at the GIN GRUU construction. It looks correct to me, and the split between required and optional seems sensible. My summary of the algorithm is below, in case it's helpful. The security requirements 2 and 3 in 7.1.2.1 seem poorly specified (1, 4, and 5 seem obvious enough). W.r.t. 2: It seems like the risk here is that a PBX might be able to make GRUUs that route to another PBX, which is the opposite of what this says. W.r.t. 3: The current algorithm doesn't protect against this; it would need something related to time. {{{ ===== KEYS ===== Key Type Known to SK_SSP HMAC key SSP pk_SSP Private key SSP Pk_SSP Public key SSP, PBX SK_PBX HMAC key PBX ===== GENERATION ===== SSP (general): cookie = [ random; identifies PBX; fixed-length ] SSP (optional): I = [ identifier for PBX ] J = HMAC(SK_SSP, I) // Prevents spoofing cookies if I is known but not SK_SSP cookie = I || J SSP -> PBX: cookie PBX: D = [ per-temp-GRUU random ] M = cookie || D E = RSA_Encrypt(Pk_SSP, M) PA = HMAC(SK_PBX, E) PBX -> UA: temp-gruu = [ E, PA ] ===== VALIDATION ===== UA' -> SSP: temp-gruu = [ E, PA ] SSP (general): M' = RSA_Decrypt(pk_SSP, E) cookie' = [ truncated M' ] cookie-valid = [ proprietary ] SSP(optional) M' = RSA_Decrypt(pk_SSP, E) cookie' = [ truncated M' ] I', J' = [ split cookie' ] cookie-valid = (J' == HMAC(SK_SSP, I')); SSP (general): if (cookie-valid) generated by SSP for PBX identified by I' SSP -> PBX: temp-gruu' = [ E, PA ] PBX: if (PA == HMAC(SK_PBX, E)) generated by PBX for UA identified by 'gr' }}} -- Comment(by henrik@…): ( Made the wiki markup engine treat part of the description as literal text, to avoid the weird formatting we got when it tried to apply markup rules ... ) -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/56#comment:5> martini <http://tools.ietf.org/martini/>
- [martini] #56: GRUU mechanism security review martini issue tracker
- Re: [martini] #56: GRUU mechanism security review martini issue tracker
- Re: [martini] #56: GRUU mechanism security review martini issue tracker
- Re: [martini] #56: GRUU mechanism security review martini issue tracker
- Re: [martini] #56: GRUU mechanism security review martini issue tracker
- Re: [martini] #56: GRUU mechanism security review martini issue tracker
- Re: [martini] #56: GRUU mechanism security review martini issue tracker