Subject: Re: [Sip] GRUU and Anonymity

From: [email-masked]
Date: Tue, 12 Sep 2006 10:58:49 -0400

I don't see generating TRUUs (thanks, Jeroen!) as being that
difficult, even without going back to the Registrar for them.  The
following is a half-baked scheme to create TRUUs with serial and
temporal anonymity (thanks, Jonathan!).  But if I can cook this up in
5 minutes, someone who knows crypto should be able to devise something
that works in practice.

    The proxy gives the UA a GRUU used only for generating and routing
    TRUUs.  (This GRUU can be custom-made for this purpose by the UA
    generating a random UUID URN for use as an instance-ID.)

    The proxy also gives the UA a proxy-specific public key, PublicKey.

    The UA will generate a sequence of TRUUs, TRUU(0), TRUU(1),
    TRUU(2), etc.  The UA keeps a sequence counter for generating
    TRUUs, with permanent storage of: the last sequence number used, a
    sequence number before which all TRUUs are known to be invalid, and
    for those sequence numbers in between those two numbers, which are
    valid and which are invalid.

    (Perhaps a TRUU is used for just one call, and after that call is
    over, that TRUU is marked invalid.  A "call" may involve more than one
    dialog at the SIP level.)

    TRUU(n) = PublicKey(GRUU concat SequenceNumber)

    When a request with an TRUU as the request-URI arrives at the proxy,
    the proxy calculates:
        (GRUU, SequenceNumber) = PrivateKey(TRUU)
    It rewrites the request-URI to be the GRUU and appends a parameter to
    carry SequenceNumber.

    When the request arrives at the UA, it examines the SequenceNumber to
    determine whether to accept the request or not.  If it wants to reject
    the request, it does not respond 404 (as that may give away
    information about the UA), but rather 301 (Moved Permanently!) with a
    Contact address that is known to be invalid in the proxy's domain.
    The proxy will then generate a 404.

    Only the UA (or proxy) can generate the UA's TRUUs because only it
    knows its GRUU.  Since the proxy does not let the UA know the
    private key, malfunctioning UAs cannot disclose the private key,
    so no third party can dissect a TRUU.

Dale

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Sep 2006 13:32:28 -0400

Dale,

I'm not sure I follow all the details, but I get the gist. I gather the 
proxy isn't expected to have any idea which sequence numbers are/aren't 
valid. If so, then it seems that the sequence number is analogous to the 
grid parameter. It may be possible align the two approaches closely.

For instance, perhaps the normal gruu is of form:
	sip:user@domain;gruu;opaque=xyz;grid=abc

Then an anonymous form of it could be
	sip:PublicKey(user,opaque,grid)@domain;gruu

and as you suggest, the proxy could turn this back into the 
non-anonymous form and then process it normally. Ultimately the UA would 
receive the grid.

But a piece I am missing in the above and below is how the proxy 
determines what private key to apply to the incoming truu. It could 
potentially get the one currently assigned to a registered contact, but 
to do so it would need to know what user, and then which contact.

I guess the anonymous form of the gruu could be:
	sip:PublicKey(user,opaque,grid)@domain;gruu;key=foo

where foo is either the public key or an index into all the private keys 
held by the proxy. But that then provides a value that can be used to 
correlate anonymous gruus from the same source. And it also dictates 
some special state storage in the proxy.

Another messy aspect of this is that it couples the UA and the proxy 
regarding the details of the format of the URI, and that might cause 
some difficulties.

For instance, one problem I have encountered with IMS (and which may 
apply to other large domains) is that the user space is partitioned, 
with a different home proxy handling each partition. In the kind of 
scheme you have proposed, it becomes necessary to guarantee that 
anonymous gruus are routed to the proper home proxy. There are no doubt 
a bunch of ways to do that, but I think it all comes down to either 
making a shared table of all the assigned anonymous gruus, or else 
putting something into the gruu that correlates 1:1 with which home 
proxy is responsible. The shared table seems expecially troublesome. 
Providing correlator to the home proxy is less so, but may still be 
offensive to some. Coming up with a mechanism that distributes the 
construction to the UA while providing the system enough flexibility 
about how the result is structured is at least a little tricky. This is 
the "generator" that Jonathan was talking about as an alternative.

	Paul

---

From: [email-masked]
Date: Tue, 12 Sep 2006 15:25:17 -0400

From: Paul Kyzivat <[email-masked]>

The reason that the pseudo-grid's are numbers is so that the UA can
store a threshold, before which all pseudo-grid's are known to be
invalid.  If they didn't form an ordered sequence, the UA would have
to record in non-volatile memory all invalid ones.  Or all valid ones.

Uh, yes, the number of valid ones at any given moment is expected to
be small.  So you don't really need them to be numbers, as long as
there is some way to avoid using the same one twice (very often).

There's only one private key for the domain.

Yeah, it's a pretty tight coupling between the processing in the proxy
and in the UA.  In particular, they have to implement opposite halves
of the encryption operation.

   anonymous gruus are routed to the proper home proxy.

Not really.  Since there is only one private key, any proxy can open
any TRUU for the domain.  Once it does that, it has the GRUU for the
UA, but we already assume that any proxy can route any GRUU for the
domain.

This scheme seems to have a problem in that it's not too hard to forge
TRUUs that might get partially routed before they are rejected.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Sep 2006 10:12:16 -0400

> there is some way to avoid using the same one twice (very often).

The way the values are tracked by the UA isn't relevant to the 
mechanism. If a UA wants to use grid values that are monotonically 
increasing integers, in order to simplify tracking which are still 
valid, then it is free to do so. If it wants to use callids, then it can 
do that. Whatever.

> There's only one private key for the domain.

Oh! I didn't guess that. That seems like a fatal flaw. Once it is 
cracked, it is cracked for everybody. And it will be hard to change if 
it is compromised.

> of the encryption operation.

That part isn't so bad. But it also couples other aspects of formatting 
the anonymous gruu. (Does it have the same domain as the regular gruu? 
Does it have parameters? Is it necessary to provide a standard prefix or 
suffix to the encrypted part before putting it into the URI?)

I have no doubt that we could come up with some flexible scheme for 
this, characterized by a few parameters. But then we need to convey 
those parameters, etc. Its not a show stopper, but its unpleasantly 
complex to cover in general.

> UA, but we already assume that any proxy can route any GRUU for the

If there is only one key, then I agree the problem is simpler.
But I have to believe that the key will need to change from time to 
time. That results in a key distribution problem.

It would be way safer if there was a separate key for every gruu. But 
that leads to all the other problems I have been worrying about.

> TRUUs that might get partially routed before they are rejected.

I think there are different views of how important a problem that is. It 
doesn't bother me so much.

	Paul