[OpenSIPS-Users] learning the realm from authentication challenges

Fri Sep 25 18:31:13 EST 2020

Don't forget to deal with CSEQ increment on the authenticated INVITE.

Also we had problems when any in-dialog message is received, we have to
deal with CSEQ on all of them. =(

On Fri, Sep 25, 2020 at 12:30 PM johan <johan at democon.be> wrote:

> Jeff, be warned that the datafill for registrar is not obvious.
> On 25/09/2020 16:40, Jeff Pyle wrote:
>
> I am not route-advancing in a typical way, so my application of
> credentials is a bit different perhaps.
>
> The environment I'm in has a variety of customer-facing platforms, over a
> dozen at last count.  Some are for trunking, some hosted, some hybrid.  The
> platform I'm writing on OpenSIPS is a testing one that will allow us to
> send and receive test calls to and from all of them.  So, rather than
> having a bunch of registrations on every test phone for every person who
> might want to test, this allows each person to have one appearance to this
> platform and select which upstream platform they want to send a call to via
> dialed prefixes.
>
> I use the uac_registrant module, and its registrant table, to handle the
> platforms that require registrations and it works excellently.  At call
> time, I'm working on the scripting right now that will query the registrant
> table for the appropriate credentials based on where we've sent the call
> and apply them in the failure_route upon receiving a 401 or 407.
>
> Think of it this way:  when you configure a gateway in FreeSWITCH or a SIP
> peer in Asterisk's chan_sip, do you need to define the realm ahead of
> time?  No, you don't care; it's just a mechanism under the hood that's
> necessary to complete the transaction.  That's where I'm at in OpenSIPS.
> With Johan's parsing it looks like I'm about there, too.  Friggin' regex
> gets me every time.
>
>
> - Jeff
>
> On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin <Ben.Newlin at genesys.com>
> wrote:
>
>> I think you do need to have credentials associated with the different
>> routes you have and load those properly. From your description, however, I
>> don’t understand why it is dependent on identifying the realm in the
>> response. If multiple downstream servers are all using the same realm (but
>> have different credentials?) then how are you differentiating based on the
>> realm value?
>>
>>
>>
>> The idea with uac_auth is that when you send, for example, to server
>> broadworks1 you would load all the possible valid credentials for
>> broadworks1, including the realm it will challenge with. When you then call
>> uac_auth() from failure route, it will look through all the loaded
>> credentials for one with a matching realm to the broadworks1 challenge and
>> use that. If the call fails for any reason to broadworks1 and then you
>> decide to route to server asterisk1, you would load all the possible
>> credentials for that server into the auth AVPs the same way and failure
>> route handling is the same.
>>
>>
>>
>> You could very well have a use case for verifying the realm in
>> failure_route; I’m not saying you don’t. I don’t see it from what you’ve
>> described, but I may be missing something. I think the reason there is no
>> variable for pulling the challenge realm value directly is because normally
>> with this mechanism it shouldn’t be needed.
>>
>>
>>
>> I would appreciate if someone could confirm that uac_auth() will match
>> the realm as I’m asserting. I’m 95% sure this is how it worked in my
>> testing, but that was a while ago and as I said the realm matching doesn’t
>> appear to be documented. I’d hate to be steering you down a wrong path.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users <users-bounces at lists.opensips.org>
>> *Date: *Friday, September 25, 2020 at 10:15 AM
>> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
>> challenges
>>
>> Johan,
>>
>>   I will definitely try that.  Thank you!
>>
>>
>>
>> Ben,
>>
>>   The problem is I have multiple destinations with the same realm.  In my
>> case, several different Broadworks app servers.  I haven't checked them
>> exhaustively but I think they all reply with realm="BroadWorks" in their
>> authentication headers.  I've got some Asterisk boxes in here, and I think
>> they're all the domain of the SIP request URI in the case of an INVITE.  I
>> think I'll have to choose ahead of time which credentials go with which
>> route, no?  Unless I'm still not wrapping my head around how this is
>> supposed to work.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin <Ben.Newlin at genesys.com>
>> wrote:
>>
>> Jeff,
>>
>>
>>
>> My point was that the uac_auth() is supposed to handle the realm matching
>> for you. If you simply load all of the auth data based on the call target
>> as you already plan to do, uac_auth() should look through that data for you
>> to find credentials with a matching realm. You don’t need to do that part
>> yourself in the script.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users <users-bounces at lists.opensips.org>
>> *Date: *Thursday, September 24, 2020 at 11:14 PM
>> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
>> challenges
>>
>> Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've
>> been looking at this too long.  I checked the module and that's exactly
>> what it is.
>>
>>
>>
>> My hope was to load the uac_auth user/pass AVPs ahead of time from a DB
>> based on where I knew I was sending the call, load the realm one in the
>> failure route based on what comes back in the header, and then fire the
>> uac_auth() function.  It looks like I may have to manually extract the
>> realm from whichever header comes in.  Not ideal, but probably workable.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>> On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin <Ben.Newlin at genesys.com>
>> wrote:
>>
>> This does not appear to be documented, but I believe uac_auth() looks
>> through the AVPs configured in the UAC_AUTH module and uses the first one
>> whose realm matches the challenge realm. So in order to authenticate any
>> challenge, you must load all of the possible credentials into those AVPs.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users <users-bounces at lists.opensips.org>
>> *Date: *Thursday, September 24, 2020 at 9:53 PM
>> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
>> challenges
>>
>> According to the docs, $ar provides the realm from the “Authorization” or
>> “Proxy-Authorization” headers. Not from the ”Proxy-Authenticate” header,
>> which is what you have.
>>
>>
>>
>> https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users <users-bounces at lists.opensips.org>
>> *Date: *Thursday, September 24, 2020 at 9:31 PM
>> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>> *Subject: *[OpenSIPS-Users] learning the realm from authentication
>> challenges
>>
>> I'm trying to recover the realm of an auth challenge to OpenSIPS so I can
>> respond to it with the uac_auth() function, and that requires knowing the
>> realm.  The docs say that $ar
>> <https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6> should
>> provide that, perhaps written like $(<reply>ar) to get it in the right
>> context.  I'm having some trouble getting the data.
>>
>> failure_route[relay_failure] {
>> ...
>>
>>         if (t_check_status("407")) {
>>                 xlog("L_NOTICE", "[1] Proxy-Authenticate:
>> $(<reply>hdr(Proxy-Authenticate))\n");
>>                 xlog("L_NOTICE", "[2] Auth Realm: $(<reply>ar)\n");
>>
>>                 xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
>>         }
>>
>> ...
>>
>> }
>>
>>
>>
>> The logs show:
>>
>> /usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
>> realm="asterisk", nonce="5f6d42140000936ad820dbcd452e6bcd145777e458dd46dd",
>> qop="auth"
>> /usr/sbin/opensips[33044]: [2] Auth Realm reply: <null>
>> /usr/sbin/opensips[33044]: [3] Auth Realm: <null>
>>
>>
>>
>> Is it possible to get the realm?  Is it possible to build a response with
>> uac_auth() for an arbitrary authentication challenge?
>>
>>
>>
>> This is on 3.1.0~20200923~88f89e941.
>>
>>
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200925/938f1a51/attachment-0001.html>