< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] Can a BYE be challenged?


Andrew - I think you read more into whatever you saw than was there - can you go find what you read again? 401/407 based authentication is scoped to the request containing valid credentials and no more.

Matthias - You've run head-on into one of the big weaknesses of the challenge-response model applied to SIP - problems like this one are what motivated the SIP Identity header. In real-world environments, using DIGEST to authorize BYEs is all but pointless - its better to use the fact that the other end is presenting the correct dialog state for your admission decision. The problem with trying to challenge BYE is coming up with a reasonable thing to do if the other side never presents valid credentials - in most cases, you're just going to terminate the dialog _anyway_. Likewise, if some UAS decides it doesn't like the credentials in your BYE, and there's nothing you can do to make it happy, you're not going to just keep the dialog going - you're going to declare the other side broken and abandon your end.

The main reason people try is to protect against some 3rd party sending a spoofed BYE to end the dialog relationship. For the 3rd party to succeed, they need access to at least the current dialog state, and if they are that far into the game, spoofing BYEs is not necessarily at the top of the list of harmful things they can do. If you really need to protect against these, you should be looking at using things like TLS and SIP Identity as part of your admission decision.

RjS



On Mar 3, 2009, at 12:26 PM, Andrew Wood wrote:

I believe the authorisation is only supposed to be done once for the entire dialog. I read that somewhere a few weeks back probably in the RFC.

Andrew

Matthias Moetje wrote:

Hi,


short question: our resiprocate application tries to challenge (sends 407) a BYE sent from the remote party but the remote party continues to send BYE without proxy authorization. Is it a fault on our side or a problem of the remote implementation?



Best regards,


Matthias Moetje

*TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY*

        


        

*Phone:
Fax:
e-mail:
Web:*

        
        

*+49.89.143370-0
+49.89.143370-22
**info@xxxxxxxxxxxx <mailto:info@xxxxxxxxxxxx>
www.terasens.com <http://www.terasens.com/>*




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
------------------------------------------------------------------------

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/