Subject: [martini] New version of GIN (-03) -- temp-gruu fix

From: Adam Roach <[email-masked]>
Date: Fri, 21 May 2010 17:09:15 -0500

Based on the recent discovery that the temp-gruu portion of GIN was 
actually broken as written, I've ripped out the previous mechanisms and 
replaced them with one based on the algorithm in Appendix A.2 of the 
GRUU RFC. The actual algorithm has been modified slightly to split 
duties between the SSP and the PBX, but the security properties should 
be substantially identical.

This version also addresses some errors in the examples and other nits 
that have been brought to my attention.

New version:
   http://www.ietf.org/id/draft-ietf-martini-gin-03.txt

Diffs:
   http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-03.txt

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 May 2010 17:11:27 -0500

I recognize that this comes pretty swiftly on the heels of the -02 
update. If you'd like to see a diff between -01 and -03, you can get one 
here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-03.txt&url1=draft-ietf-martini-gin-01.txt

/a

On 5/21/10 5:09 PM, Adam Roach wrote:
> actually broken as written, I've ripped out the previous mechanisms 
> and replaced them with one based on the algorithm in Appendix A.2 of 
> the GRUU RFC. The actual algorithm has been modified slightly to split

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 10:36:30 +0200

"   A registrar that receives a URI with both a "bnc" parameter and a
   user portion MAY discard the user portion and process the request as
   if it were not present.  Alternately, the registrar MAY return a 400
   (Bad Request) error in response.

      Note that this requirement is talking about the user portion of a
      URI:

      sip:[email-masked];user=phone
          ^^^^^^^^^^^^"

Since this is specifically talking about the user portion, I would suggest suppressing ";user=phone" from this example. This is later text (in 5.3) specifically outlawing the "user" parameter with "bnc", so including it in the example in 5.2 is confusing.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 21 May 2010 23:09
> To: [email-masked]
> Subject: [martini] New version of GIN (-03) -- temp-gruu fix
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 10:58:15 +0200

Adam,

"K_e2 is shared with the PBXes via
   provisioning." 

It would be nice to avoid this. Any reason it can't be shared by means of the 2xx response to REGISTER?

John

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 May 2010 10:02:14 -0500

> It would be nice to avoid this. Any reason it can't be shared by means of the 2xx response to REGISTER?

It's a bit too large for that. Even for a 1024-bit key (which is pretty 
much the smallest RSA key one would consider using), you're looking at 
171 bytes once you've base-64 encoded them. 2048-bit keys, which are not 
unrealistically large, would be 342 bytes long.

I think these would pose very real problems in a REGISTER response.

I did briefly think about using draft-ietf-sip-certs to get keys, but 
that introduced even *more* complexity. Plus, it can be added on as an 
extension at a later date if people really want it. But I think we'd be 
really getting out way in front of demand if we did that now.

/a