Subject: [Sip] GRUU state and cancellation

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Sep 2006 12:19:41 -0700

There was some discussion on the call today about GRUUs and state
storage.

The general technique for stateless GRUUs is of course to push all the
state into the GRUU and use a cryptographic MAC to determine validity
and prevent tampering. I.e., you have a permanent key K and then the
GRUU is constructed as:

        G = GRUU-data || R
     GRUU = G || HMAC(K, G)

Where R is randomly generated. You can obviously determine whether any
GRUU is valid by checking the HMAC and you don't need to store any local
state other than K.

This doesn't allow for any kind of cancellation or revocation, but those
can be provided with fairly limited state storage. The two obvious
options are Bloom filters and bitfields.

The Bloom filter approach is simple is to just insert any revoked
GRUU into the Bloom filter. This works pretty well as long as the
fraction of revoked GRUUs is fairly small but once it gets fairly
high the Bloom filter starts to fill and you get false positives.
So, it only makes sense if you only very occasionally want to
revoke a GRUU which is the target of abuse.

The bitfield approach is to give each GRUU a sequence number N, like:

        G = GRUU-data || R || N

You then just maintain a bitfield with a bit corresponding to each
value N, with a low-water mark indicating the earliest valid N
(you can also use run-length encoding, etc.) This approach makes
a lot more sense if you're mostly issuing single-use GRUUs and
you just want to remember them while they're still valid. 

-Ekr

P.S. There's a lot of analysis of a related system with much
higher churn rates (SSL servers) in:

H. Shacham, D. Boneh, and E. Rescorla. "Client-Side Caching for TLS",
ACM Trans. Info. & Sys. Security, 7(4):553-75, Nov. 2004. 
http://www.hovav.net/dist/sslex.pdf

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip