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/>