Re: [reSIProcate-users] Can a BYE be challenged?
Robert and Andrew,
thanks for your help!
As far as I understand Repro uses an AclStore in oder to just require a
challenge on the first request and then store this in the AclDB. In fact this
seems to act like what Andrew described.
I used some of the repro code for our B2BUA and resembled the concept of the
AclStore. Though, when the first request from the remote side is a BYE and the
remote side (asterisk in my case) does not authorize the BYE correctly, the
call never gets disconnected on our side.
I think I should return false in ServerAuthManager:RequiresChallenge for BYE
messages like Robert suggested.
Are there any other requests I should exclude from being challenged?
Best regards,
Matthias Moetje
______________________________________________
TERASENS GmbH Phone: +49.89.143370-0
Augustenstraße 24 Fax: +49.89.143370-22
80333 Munich e-mail: info@xxxxxxxxxxxx
GERMANY Web: www.terasens.com
______________________________________________
> -----Original Message-----
> From: resiprocate-users-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-users-
> bounces@xxxxxxxxxxxxxxx] On Behalf Of Robert Sparks
> Sent: Dienstag, 3. März 2009 19:54
> To: Andrew Wood
> Cc: resiprocate-users@xxxxxxxxxxxxxxx
> Subject: 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/
>
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/