[Sipping] Re: [VOIPSEC] VoIP Spam paper

[Hannes Tschofenig <[e-mail]>]

Hi Vijay,

sorry for the late response.

First, I would like to start with a high-level observation. You are 
combining authentication and authorization in your documents. I don't 
believe that this is really necessary. SPIT prevention is largely an 
authorization problem that can be separated from the specific details of 
how authentication was done. This is also true for the current SIP work 
where various mechanisms are available for authentication but they are 
largely decoupled from the authorization policy framework used, for 
example, in the presence authorization policy work or for media 
security. Our work on SPIT prevention focuses on the authorization part 
since there is a lot of prior work in the context of SIP-based 
authentication that can be leveraged without introducing a lot of 
dependency. For us, there is very little reason to come up with new 
solutions in the authentication space only for SPIT prevention usage.

Now, I have some comments for you inline:

vijay arvind wrote:
> Hello Hannes,
> Thanks for introducing the paper to the larger community. Was away for
> thanksgiving so could not respond earlier. I have a few
> additions/corrections to what has been mentioned in your mail:
>
> 1) The contents of the call credential:
> The call credential contains the following information, in addition, to
> provide sender authentication and remove the possibility of credential
> misuse:
> Identity of Caller, Public Key of Caller, Identity of Call Recipient, Public
> Key of Call Recipient, Call Duration, Timestamp, {all the previous info
> encrypted with the callers private key}.
> This ensures multiple things
>   

In the context of our work I guess we are largely interested only in the 
"Call Duration" part of your solution (rather than the authentication 
specific parts).

> a) If Alice and Bob know each other (and have each others public keys as
> described in work
> http://www-static.cc.gatech.edu/~vijayab/locating_SIP_users.pdf), then when
> Charlie calls with a credential from Bob, Alice can actually ensure the
> credential is from Bob.
>   
The case where they know each other (and they are already on each 
other's buddy list) is easy.

I browsed through the paper and I believe you describe the SIP CERT 
concept.
I am not sure whether your understanding of SIP digest and SIPS usage 
matches my understanding.
You might want to double-check your performance results.

> 2) Deployment:
> Quoting Hannes: "Although not stated explicitly, I assume that information
> about a users
> call patters are stored with its VoIP provider."
> This is not how the paper extracts information about a user. Consider user
> Alice who uses say Vonage's VOIP service and thus all calls to and from
> Alice pass through Vonage's proxy server. Now lets say user Dave wants to
> call Alice and is using some VoIP provider X. Then Dave's reputation (if he
> doesnt have an SN credential) is assigned by the Vonage proxy and built on
> all the interactions (call history) that Vonages' customers have had with
> him.
I see. In essence, you are saying that every VoIP provider would story 
information about customers of other VoIP providers IF they have ever 
called a user of that domain (+ maybe considering "garbage" collection 
via a TTL).

When someone uses SIP privacy mechanisms then they would never gain 
reputation in the way how your system works since SIP privacy hides the 
identity of the caller towards the callee (including the domain of the 
destination).

>  So the reputation for an incoming call is assigned by the proxy of the
> call recipient (that is Alice's Vonage proxy).

Wouldn't the caller's home domain be the most likely party that knows 
something about the call pattern of that user?

>  So Vonage will thus have a
> reputation matrix of all users of Vonage and all users that Vonage users
> have interacted with and then assign reputations (based on
> Eigentrust(pagerank)) to them. Daves proxy X has no say in this matter.
>   
Got it.

> Therefore if a particular VoIP provider provides this reputation calculating
> mechanism, users of that VoIP provider can utilize it and we expect the
> deployment to work that way.
>
> 3) Privacy aspects:
> The paper as it stands now has privacy issues with regards to its credential
> sharing mechanism. We have come up with a way to address that and that will
> be available along with an actual implementation of CallRank that we are
> building on MjSip as a client and OpenSER as the proxy server.
>   
I am looking forward to see how it works.

> 4) Future work:
> In addition to what is already mentioned we realize that for each proxy to
> calculate the reputation matrix for a large number of users we need far more
> intelligent, efficient ways of calcualting the reputation matrix. We find
> that there are ways in which we can organize the matrix to come up with
> efficient and accurate reputation calculations. All this and more are part
> of the next paper that we are working on.
>   
Excellent.

> I hope I have clarified certain things that we could not provide in all
> detail in the paper due to space constraints.
>   
Yep. Your comments have helped me a lot. Thanks.

Ciao
Hannes

> Bye,
> Vijay
>
> On Nov 25, 2007 5:32 AM, Hannes Tschofenig <[e-mail]>
> wrote:
>
>   
>> Hi  all
>>
>> BACKGROUND
>>
>> In the IETF SIPPING WG we had discussions regarding SPIT prevention
>> mechanism. Particularly with regard to the SPIT marking techniques it
>> seems that there is some disagreement about the usefulness of
>> statistical techniques. A number of ideas have been discussed already on
>> various IETF mailing lists.
>> I would like to bring another paper to your attention that has been
>> posted to the VOIPSEC mailing list.
>>
>> THE PAPER
>>
>> The paper says that it exploit the fact that in regular communication
>> users both make and receive calls, while spammers are interested in only
>> making calls and disseminating information. This paper takes existing
>> work from the email environment and applies it to VoIP (as it seems).
>>
>> The basic idea is to observe communication and call duration in
>> particular. Thereby, the call duration is used to create, so-called call
>> credentials. A call credential CC consists of A, the identity of the
>> caller, B, the identity of the call recipient, t, the call duration and
>> TS, the time stamp of the call along with a digital signature of the
>> same information.
>>
>> Although not stated explicitly, I assume that information about a users
>> call patters are stored with its VoIP provider. Then, when a user makes
>> a call information about the call patters (i.e., in the form of call
>> credentials) are made available to the receiving domain or other end
>> point. Sharing information about the sender with the recipient's domain
>> or the recipient itself has been described in
>> http://tools.ietf.org/id/draft-schwartz-sipping-spit-saml-01.txt
>> (although no reference to that document is included in the paper). This
>> work on utilizing social networks, as described in
>> http://tools.ietf.org/id/draft-ono-trust-path-discovery-02.txt, might
>> also be applicable.
>>
>> To deal with the introduction problem turing tests are suggested.
>>
>> Working on draft-schwartz-sipping-spit-saml-01.txt we encountered
>> problems, such as
>>
>> * Deployment challenge to get SPIT SAML to deploy. Without it being
>> widely deployed the receiving domain does not have a way to know
>> anything about the call statistics. Hence, the mechanism would only work
>> within a single domain. Without sufficient deployment the mechanisms
>> described in the paper wouldn't be so useful either. As such, this
>> deployment challenge has nothing todo with SAML but is rather a generic
>> problem with the solution approach outlined in the paper (although the
>> authors claim it differently in Section 2.4 "Related Work").
>>
>> * Privacy aspects: It is not clear whether it is actually possible to
>> distribute some of this information from one domain to another one
>> without violating some privacy laws.
>>
>> * Trusting the information provided by the sending domain is likely to
>> work only for larger VoIP providers. In the worst case the Spammer might
>> provide this information since he is acting as a VoIP provider.
>>
>> The idea of using call patterns for SPIT prevention is not new. Still,
>> the provided details for using the call duration (using the Eigentrust
>> algorithm) in a SPIT prevention scenario are nice. Maybe this paper
>> provides a different spin to our SPIT marking discussion.
>>
>> Ciao
>> Hannes
>>
>> PS: http://tools.ietf.org/id/draft-schwartz-sipping-spit-saml-01.txt did
>> not describe which algorithms to use to compute some of the parameters.
>> I believe that this is fine for an IETF document given that there are a
>> lot of implementation specific aspects that are not relevant for
>> standardization.
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: [e-mail] [mailto:[e-mail]] Im
>> Auftrag von ext vijay arvind
>> Gesendet: Montag, 12. November 2007 00:34
>> An: [e-mail]
>> Betreff: [VOIPSEC] VoIP Spam paper
>>
>> Hello All,
>>
>> Attached is a link to a VoIP spam approach that we at the Georgia Tech
>> Information Security center (GTISC) are working on and was presented at
>> the
>> 4th conference of Email and Anti Spam:
>> http://www.ceas.cc/2007/papers/paper-63.pdf
>>
>> The basic idea is to try and exploit the fact that in regular
>> communication
>> users both make and receive calls, while spammers are interested in only
>> making calls and disseminating information. Users rarely call a spammer
>> and
>> even if they inadvertently do so, the call will last for a small duration.
>> Hence we use call duration and the directionality of calling patterns to
>> distinguish between a regular user and a spammer. We use basic
>> cryptographic
>> primitives to encapsulate call duration as call credentials. How we
>> combine
>> these call credentials using social networking theory and the Eigentrust
>> algorithm (PageRank) to create a spammer detecting mechanism forms the
>> crux
>> of the paper.
>>
>> Bouquets and Brickbats are most welcome.
>>
>> Thanks,
>> Vijay
>> _______________________________________________
>> Voipsec mailing list
>> [e-mail]
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>>
>>     
>
>   



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