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

From: "martini issue tracker" <[email-masked]>
Date: Fri, 16 Jul 2010 17:32:18 -0000

#56: GRUU mechanism security review
-----------------------------+----------------------------------------------
 Reporter:  rbarnes@…        |       Owner:            
     Type:  defect           |      Status:  new       
 Priority:  major            |   Milestone:  milestone1
Component:  gin              |     Version:  1.0       
 Severity:  In WG Last Call  |    Keywords:            
-----------------------------+----------------------------------------------
 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'

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/56>
martini <http://tools.ietf.org/martini/>

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 16 Jul 2010 22:16:02 -0000

Comment(by adam@…):

 More from Richard:

 I guess the attack you can accomplish by sending messages to another PBX
 is a DoS, when SSP-capability > PBX-capability.  To that extent, it makes
 sense to have the HMAC on I.  The countervailing risk is that you could
 overwhelm the SSP server with HMAC computations by sending bogus HMACs,
 but HMACs are so cheap that seems unlikely -- it would get overwhelmed by
 the RSA decryptions first.  (Actually, that risk might be worth
 documenting in the Security Considerations; might want to rate-limit
 requests to temp-GRUUs.  No, I haven't looked to see if it's already
 there)

 I don't see any harm in removing 2 and 3, in any case.

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

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 16 Jul 2010 22:16:10 -0000

Reporter:  rbarnes@…        |       Owner:  adam@…          
Changes (by adam@…):

  * owner:  => adam@…

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

---

From: "martini issue tracker" <[email-masked]>
Date: Sat, 17 Jul 2010 15:09:13 -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/>

---

From: "martini issue tracker" <[email-masked]>
Date: Sat, 17 Jul 2010 15:48:44 -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:                   |  
-----------------------------+----------------------------------------------
Changes (by adam@…):

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

Comment:

 Reopening: there are some changes indicated by the security review --
 removing properties 2 and 3 from the list, and including Richard's concern
 in the Security Considerations section.

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

---

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Jul 2010 12:39:57 -0000

>      generated by PBX for UA identified by 'gr'

New description:

 {{{
 ===== KEYS =====

 Key     Type         Known to
 SK_SSP  HMAC key     SSP
 pk_SSP  Private key  SSP

 ===== GENERATION =====

 SSP (general):

 SSP (optional):

 SSP -> PBX:
    cookie

 PBX:

 PBX -> UA:
    temp-gruu = [ E, PA ]

 ===== VALIDATION =====

 UA' -> SSP:
    temp-gruu = [ E, PA ]

 SSP (general):

 SSP(optional)

 SSP (general):
    if (cookie-valid)

 SSP -> PBX:
    temp-gruu' = [ E, PA ]

 PBX:

 }}}

--

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