[EMAIL PROTECTED] wrote:
> From: Paul Kyzivat <[EMAIL PROTECTED]>
>
> IIUC, the identification is mostly just for authorization, to prevent
> fraud - getting preferential treatment.
>
> I don't think that even this mild form of fraud is a problem, as one's
> position in the queue is determined by when one makes the
> subscription. My concern is privacy -- having a CC subscription
> allows monitoring the alleged callee's presence/availability
> information without having placed a call to the callee first. Given
> current telephony usage (caller-ID), users are much more likely to be
> aware of someone calling them on a regular basis than someone
> continuously subscribed to the CC service. And given the
> near-anonymity of SIP requests, it would be hard to detect
> privacy-invasive exploitation of CC subscriptions.
Use of the From to validate the subscription prevents casual monitoring
of callee availability. The subscription would only be authorized if
there was a call attempt with that From address that is still eligible
for CC.
Admittedly it isn't very strong. If you can guess somebody who has made
a call attempt you can bypass this. But it might be strong enough for
the purpose. How is it worse that making the call attempt and canceling
the call after the first provisional response? The presence of the
subscription, with its routing info, allows the callee to identify who
is watching if they are paranoid about it.
And I suppose this could be combined with some other sort of
authorization. There could be one mechanism with a cookie for those who
can support it, and this weaker mechanism could require some special
credential or a whitelist, that was by policy restricted to gateways.
Paul
> If you have two ways, and one of them provides an opportunity for fraud,
> and the other not, then those intent of fraud will use the one that
> supports it. There is then little motivation to implement the other
> method, since it will only be used by those who would do the right thing
> with the weaker mechanism.
>
> If you replace "fraud" with "invastion of privacy", this is my
> concern.
>
> Huelsemann, Martin wrote:
> Can't this be done by 2 different ways? First the normal way with
> delivering something like a CC identifier back to the CC agent
> which then ist used druring the subscription and the CC call. The
> other way would be the fallback for stateless UAs (and gateways) to
> reassemble the identifier from information available from the
> original call (first choice information about caller and
> callee). During design team discussion Dale also introduced a
> keying mechasim guarateeing privacy settings.
>
> The difficulty with a keying mechanism is that we cannot assume that
> the caller's agent and the callee's monitor share a key. I doubt that
> we could implement that in practice even in a walled-garden run by a
> bureaucratic service provider.
>
> Once we decide that the key is present only in the caller's agent, we
> have a need to transmit the key-derived identifier to the callee's
> monitor. But at that point there is a conflict -- we don't want to
> add to every INVITE an additional datum, but at the same time, all the
> data in an INVITE seem to be either easily guessable or intermediate
> B2BUAs feel free to change them.
>
> Perhaps we need to study more carefully whether this is needed to
> prevent abuse of privacy.
>
> Dale
> _______________________________________________
> BLISS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
