[Jingle] Comments on XEP-0251 standard

Dawid Nowak dawid.nowak at nortel.com
Fri Apr 24 04:56:59 CDT 2009


Hi,

This is a grea learning experience :) Anyway I don't think it will make it any safer. To prove the point check "The Session Initiation Protocol (SIP) Refer Method" Section 5.2 Authorization Considerations for REFER. Here is a citation that higlights my point.

5.3.1 Circumventing Privacy

   Suppose Alice has a user agent that accepts REFER requests to SIP
   INVITE URIs, and NOTIFYs the referrer of the progress of the INVITE
   by copying each response to the INVITE into the body of a NOTIFY.

   Suppose further that Carol has a reason to avoid Mallory and has
   configured her system at her proxy to only accept calls from a
   certain set of people she trusts (including Alice), so that Mallory
   doesn't learn when she's around, or what user agent she's actually
   using.

   Mallory can send a REFER to Alice, with a Refer-To URI indicating
   Carol.  If Alice can reach Carol, the 200 OK Carol sends gets
   returned to Mallory in a NOTIFY, letting him know not only that Carol
   is around, but also the IP address of the agent she's using.

Also SIP relies on Proxies where a proxy can interpret, and, if necessary, rewrite specific parts of a request message before forwarding it. 

My problem with this is that the protocol is not secure and we have to rely on intelligent servers to make the whole system secure. If the protocol was secured that the intelligent servers could be less intelligent and less complex I think. Also since implementation of servers is not standardized some servers are better than others but as a customer I don't really have knowledge about it. Where as if safety mechanisms are put into the protocol all entities would have to implement the same set of functionality.

Regards
D

-----Original Message-----
From: jingle-bounces at xmpp.org [mailto:jingle-bounces at xmpp.org] On Behalf Of Unnikrishnan V
Sent: 23 April 2009 20:18
To: XMPP Jingle
Subject: Re: [Jingle] Comments on XEP-0251 standard

Have look on
http://www.tech-invite.com/Ti-sip-service-5.html

and

http://www.tech-invite.com/Ti-sip-service-4.html

As  a standard, the missing thing may be the notification after disconnect of the call.

thanx
unni


On Thu, Apr 23, 2009 at 3:36 AM, Dawid Nowak <dawid.nowak at nortel.com> wrote:
> Hi,
> My understanding is that XMPP relies on trust between peers. In order 
> to be able to send an IM, receive presence notifications or make a 
> call both peers have to authorize each other. This works fine for 
> simple calls but it might not necessary work for call transfers.
>
> Caller                 Attendant                 Callee
>  |                        |                        |
>  |   session-initiate     |                        |
>  |----------------------->|                        |
>  |   ack                  |                        |
>  |<-----------------------|                        |
>  |   session-accept       |                        |
>  |<-----------------------|                        |
>  |   ack                  |                        |
>  |----------------------->|                        |
>  |   transfer             |                        |
>  |<-----------------------|                        |
>  |   ack                  |                        |
>  |----------------------->|                        |
>  |   hold                 |                        |
>  |----------------------->|                        |
>  |   ack                  |                        |
>  |<-----------------------|                        |
>  |                 session-initiate                |
>  |------------------------------------------------>|
>  |                       ack                       |
>  |<------------------------------------------------|
>  |   terminate            |                        |
>  |----------------------->|                        |
>  |   ack                  |                        |
>  |<-----------------------|                        |
>  |                 session-accept                  |
>  |<------------------------------------------------|
>  |                       ack                       |
>  |------------------------------------------------>|
>  |                    AUDIO (RTP)                  |
>  |<===============================================>|
>  |                                                 |
>
>
>
> I think the main question here is if the Caller is authorized by 
> Callee to ring him. If both are authorized than everything is well but 
> why would you need the transfer scenario. Sure Caller could ring 
> Callee directly.
>
> If the Caller is not authorized to ring Callee directly and the 
> Attendant's help is needed I think we will run into a couple of
> problems:
>
> 1. The XEP0166 says that the error should be returned if :
>        "The initiator is unknown to the responder and the responder 
> does not communicate with unknown entities."
>
> When Callee receives "session-initiate" from an unknown user it might 
> drop it straight away, but than it will never know that the call has 
> been transferred as it would have to inspect the packet in order to 
> find the "transfer" part.
>
> If we accept that the call should be accepted only if Callee trusts 
> the person who initiated the transfer (Attendant) than Callee would 
> have to inspect every "session-initiate" packet in search for the "transfer"
> part and reject the call only if the "transfer" part is not present.
> This put extra responsibility on the client, is inefficient and 
> potentially can lead to abuse of trust.
>
> If Callee accepts calls from unknown entities by default, than there 
> is no real need for the "transfer" part in "session-initiate". Surely, 
> all it has to happen is that Attendant gives Caller Callee's address.
>
> 2. Let's consider scenario in which a very annoyed Caller has saved 
> the information from the first "session-initiate" and decided to taunt 
> Callee by sending this message over and over again. Even if Callee 
> does not trust Caller it still has to search the packet for the "transfer"
> part and it should accept the call as Callee trusts Attendant. By 
> sending the same "session-initiate" packet Caller can seriously 
> degrade Callee ability to answer other calls.
>
> Another example that the transfer scenario can lead to an abuse of 
> trust is where Stalker knows that Brad and Agelina are using XMPP and 
> it can be assumed that they are peers. In order to talk to Angelina it 
> could be sufficient for Stalker to craft a "session-initiate" packet 
> with "transfer" part from Brad. Not sure if he switch could detect 
> such a breach of trust.
>
> 3. Lets imagine that Caller, Attendant and Callee are all using Google 
> clients, Caller has been authorized by Attendant but not Callee, and 
> Caller seeks revenge on Callee. When Attendant has initiated the 
> transfer Caller will know Callee's address which in this case is also 
> its email. Nothing can stop Caller from sending spam, threat, etc. to 
> Callee's account.
>
>
> Regards
> Dawid
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: jingle-bounces at xmpp.org [mailto:jingle-bounces at xmpp.org] On 
> Behalf Of Diana Cionoiu
> Sent: 17 April 2009 17:34
> To: XMPP Jingle
> Subject: Re: [Jingle] [Fwd: [Standards] Comments on xep-025 standard]
>
> Hello,
>
> Is normal for a protocol based transfer to tell the number of called 
> to the caller party. If someone wants to hide that should use an 
> intelligent jabber server.
> Anyway if you want PBX features like IVR you end up using an 
> intelligent server.
>
> Diana
>
> P.S. SIP has exactly the same behavior.
>
> Peter Saint-Andre wrote:
>> FYI regarding XEP-0251: Jingle Session Transfer...
>>
>>
>> -------- Original Message --------
>> Subject:      [Standards] Comments on xep-025 standard
>> Date:         Wed, 15 Apr 2009 18:25:40 +0100
>> From:         Dawid Nowak <dawid.nowak at nortel.com>
>> Reply-To:     XMPP Standards <standards at xmpp.org>
>> To:   <standards at xmpp.org>
>>
>>
>>
>> Hi,
>> I am no expert in XMPP but have been looking at this standard from a 
>> call centre operator perspective and have following comments :
>>
>> 1. Caller always knows the address of Callee as it gets it from 
>> Attendant in the transfer message. I suppose Callee and Attendant 
>> know
>
>> about each other but I am not sure if the same could be said about 
>> Caller. It is possible to envisage the scenario where Caller is 
>> ringing a well known public number, is asked some questions by the 
>> IVR
>
>> and transferred to a specific consultant based on hers/his answers.
>>
>> In the current proposal Attendant seems to pass Callee's address to 
>> Caller without Callee's knowledge or permission. This address could 
>> later be used to call Caller directly.
>>
>> 2. I think current proposal gives Caller too much control over the 
>> transfer and it should be Attendant who controls the transfer
> scenario.
>>
>> 3. Currently Callee can not indicate to Attendant that it can not 
>> accept transfer.
>>
>>
>> I have modified the existing diagram to reflect these points.
>>
>> Unattended transfer
>>
>> Caller                 Attendant(IVR,etc)         Callee
>>   |                        |                        |
>>   |   session-initiate     |                        |
>>   |----------------------->|                        |
>>   |   ack                  |                        |
>>   |<-----------------------|                        |
>>   |   session-accept       |                        |
>>   |<-----------------------|                        |
>>   |   ack                  |                        |
>>   |----------------------->|                        |
>>   |    AUDIO (RTP)         |                        |
>>   |<======================>|                        |
>>   |                        |                        |
>>   |                 transfer-indication             |
>>   |                                |----------------------->|
>>   |                        |          ack           |
>>   |     transfer           |<-----------------------|
>>   |<-----------------------|                        |
>>   |       ack              |                        |
>>   |----------------------->|                        |
>>   |                 session-initiate                |
>>   |------------------------------------------------>|
>>   |                 session-accept                  |
>>   |<------------------------------------------------|
>>   |                       ack                       |
>>   |------------------------------------------------>|
>>   |                    AUDIO (RTP)                  |
>>   |<===============================================>|
>>
>>
>> Where transfer-indication is:
>>
>> <iq from='attendant at office.biz/desk'
>>         id='transfer-indication1'
>>         to='boss at bigdesk.biz/phone'
>>         type='set'>
>>         <jingle xmlns='urn:xmpp:jingle:0'
>>                 action='session-info'
>>                 initiator='caller at world.sun/phone'
>>                 responder='attendant at office.biz/desk'
>>                 sid='851ba2'>
>>         <transfer-indication xmlns='urn:xmpp:jingle:transfer:0'
>>         from='caller at world.sun/phone'
>> transfer-placeholder='transfer at office.biz/transfer1'
>> transfer-id='unique-transfer-id'/>
>>         </jingle>
>> </iq>
>>
>>
>> Attendant sends Transfer back to Client. This message could also 
>> indicate that existing call between Caller and Attendant should be 
>> terminated.
>>
>> <iq from='attendant at office.biz/desk'
>>         id='transfer1'
>>         to='caller at world.sun/phone'
>>         type='set'>
>>         <jingle xmlns='urn:xmpp:jingle:0'
>>                 action='session-info'
>>                 initiator='caller at world.sun/phone'
>>                 responder='attendant at office.biz/desk'
>>                 sid='851ba2'>
>>         <transfer xmlns='urn:xmpp:jingle:transfer:0'
>>         to='transfer at office.biz/transfer1'
>>                 transfer-id='unique-transfer-id'/>
>>
>>          </jingle>
>> </iq>
>>
>>
>> And Client initiates a new session to a placeholder address which the 
>> switch translates into a valid address.
>>
>> <iq from='attendant at office.biz/desk'
>>         id='jingle3'
>>         to='transfer at office.biz/transfer1'
>>         type='set'>
>>         <jingle xmlns='urn:xmpp:jingle:0'
>>                 action='session-initiate'
>>                 initiator='caller at world.sun/phone'
>>                 sid='1a332d'>
>>                 <content creator='initiator'
>>                 disposition='session'
>>                 name='voice'>
>>                         <description
> xmlns='urn:xmpp:jingle:apps:rtp:0'
>>                   media='audio'>
>>                         <payload-type id='0' name='PCMU' />
>>                         </description>
>>                         <transport
>> xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
>>                 </content>
>>                 <transfer xmlns='urn:xmpp:jingle:transfer:0'
>> transfer-id='unique-transfer-id'/>
>>         </jingle>
>> </iq>
>>
>> Regards
>> Dawid Nowak
>>
>>
>>
>
>


More information about the Jingle mailing list