Re: [reSIProcate-users] Can a BYE be challenged?
Hi Scott,
thanks for the info, it's a while back since I had a look at the code. ;-)
Matthias
-----Original Message-----
From: Scott Godin [mailto:sgodin@xxxxxxxxxxxx]
Sent: Dienstag, 3. März 2009 22:56
To: Matthias Moetje; 'Robert Sparks'; 'Andrew Wood'
Cc: 'resiprocate-users@xxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate-users] Can a BYE be challenged?
FYI - AclStore on repro is for adding hosts that are not to ever be challenged.
An admin adds hosts to this list via the HTML admin only. It is not used for
the functionality you've described. Repro will challenge all non-ACL hosts for
each request that has missing or invalid authentication info, or authentication
info containing an expired nonce.
Scott
-----Original Message-----
From: resiprocate-users-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Matthias Moetje
Sent: Tuesday, March 03, 2009 3:23 PM
To: 'Robert Sparks'; 'Andrew Wood'
Cc: 'resiprocate-users@xxxxxxxxxxxxxxx'
Subject: 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/
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/