[OpenSIPS-Users] AVP-based uac_auth in b2bua

Jeff Pyle jpyle at fidelityvoice.com
Tue Nov 19 18:39:28 CET 2013


Ovidiu,

That makes sense.  If you're right, this feature has never worked?
Ticket<https://github.com/OpenSIPS/opensips/issues/134>submitted
(#134).  Thanks for your help.


- Jeff



On Tue, Nov 19, 2013 at 12:18 PM, Ovidiu Sas <osas at voipembedded.com> wrote:

> I think this is something that will require some coding ...
> There are two tm transactions:
>  - a UAS transaction for the received INVITE;
>  - a UAC transaction for the newly generated INVITE.
>
> The AVPs are stored by the first tm transaction and invisible for the
> second tm transaction.
> The authentication is happening on the second tm transaction and since
> the AVPs are invisible, the authentication cannot be performed.
> The parameter based authentication credentials are visible on both
> transactions and therefor the authentication process is successful.
>
> Again, this is what I think ... I haven't had a chance to check the
> code in detail.
> Best thing to do is open a bug report.
>
> Regards,
> Ovidiu Sas
>
> On Mon, Nov 18, 2013 at 9:37 PM, Jeff Pyle <jpyle at fidelityvoice.com>
> wrote:
> > Yes:
> >
> > # ----- tm params -----
> > modparam("tm", "fr_timer", 2)
> > modparam("tm", "fr_inv_timer", 118)
> > modparam("tm", "disable_6xx_block", 1)
> > modparam("tm", "restart_fr_on_each_reply", 0)
> > modparam("tm", "onreply_avp_mode", 1)
> >
> >
> > - Jeff
> >
> >
> > On Mon, Nov 18, 2013 at 7:36 PM, Ovidiu Sas <osas at voipembedded.com>
> wrote:
> >>
> >> Did you set the onreply_avp_mode for tm:
> >> http://www.opensips.org/html/docs/modules/devel/tm.html#id293972
> >>
> >>
> >> On Monday, November 18, 2013, Jeff Pyle wrote:
> >>>
> >>> It's 1.10 pulled from git a few hours ago.  Debian 7 64-bit.
> >>>
> >>> The AVPs are set prior to calling the b2b scenario:
> >>>
> >>> modparam("uac_auth","auth_realm_avp",   "$avp(auth_realm)")
> >>> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> >>> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> >>> #modparam("uac_auth","credential","UserName:AuthRealm123:SuperS33cret")
> >>>
> >>> route {
> >>>   ...
> >>>         $avp(auth_user)  := "UserName";
> >>>         $avp(auth_pass)  := "SuperS33cret";
> >>>         $avp(auth_realm) := "AuthRealm123";
> >>>
> >>>         b2b_init_request("top hiding/t105");
> >>> ...
> >>> }
> >>>
> >>>
> >>> debugs:
> >>>
> >>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback: Received reply
> >>> [407] for dialog [0x7ff941c13268], method [INVITE]
> >>> Nov 18 18:07:55 [26004] DBG:tm:t_unref_cell: UNREF_UNSAFE:
> >>> [0x7ff941c18448] after is 1
> >>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback:
> >>> dlg=[0x7ff941c13268], uac_tran=NULL
> >>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
> >>> <realm>="AuthRealm123" state=2
> >>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
> >>> <nonce>="528a9de900013e5f13fe985df4a9848356a1f937207ecfe4" state=3
> >>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body: <qop>="auth"
> >>> state=1
> >>> Nov 18 18:07:55 [26004] DBG:b2b_logic:b2bl_parse_key: hash_index =
> [472]
> >>> - local_index= [0]
> >>>
> >>>
> >>>
> >>> The following (successful) debugs occur if I uncomment the credential
> >>> modparam visible above:
> >>>
> >>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
> >>> dlg=[0x7f8a06744c30], uac_tran=NULL
> >>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
> >>> <realm>="66.94.76.24" state=2
> >>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
> >>> <nonce>="528a9fbf00014297ef8f2335679f0310537c85fe2b007186" state=3
> >>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body: <qop>="auth"
> >>> state=1
> >>> Nov 18 18:15:45 [26118] DBG:uac_auth:build_authorization_hdr: auth_hdr
> is
> >>> <Proxy-Authorization: Digest username="UserName", realm="AuthRealm123",
> >>> nonce="528a9fbf00014297ef8f2335679f0310537c85fe2b007186",
> >>> uri="sip:2165551212 at domain", qop=auth, nc=00000001,
> cnonce="3105687311",
> >>> response="ef047011046690b6eea99c7848de499a", algorithm=MD5
> >>> >
> >>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
> >>> [Proxy-Authorization: Digest ...]
> >>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback: uri [...]
> >>>
> >>>
> >>>
> >>> I tried to follow the source to isolate the failing mechanism.  I
> arrived
> >>> at modules/uac_auth/auth.c.  In get_avp_credential() at line 199:
> >>>
> >>>         avp = search_first_avp( realm_avp_type, realm_avp_name, &val,
> 0);
> >>>         if ( avp==NULL || (avp->flags&AVP_VAL_STR)==0 || val.s.len<=0 )
> >>>                 return 0;
> >>>
> >>> In my case I've discovered avp==NULL so the if-statement returns 0.
> >>> avp==NULL because in the search_first_avp() at line 346 of usr_avp.c:
> >>>
> >>>                 if (*crt_avps==0)
> >>>                         return 0;
> >>>
> >>> And it's game over.  I can't discern what causes this.  I'm already way
> >>> in over my pay grade.  :)
> >>>
> >>>
> >>> - Jeff
> >>>
> >>>
> >>> On Mon, Nov 18, 2013 at 6:02 PM, Ovidiu Sas <osas at voipembedded.com>
> >>> wrote:
> >>>
> >>> Can you post the debug logs and let us know which version of opensips
> >>> are you running?
> >>> Also, make sure that you set the credentials in AVPs before invoking
> >>> the b2b call.
> >>>
> >>> Thanks,
> >>> Ovidiu
> >>>
> >>> On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle <jpyle at fidelityvoice.com>
> >>> wrote:
> >>> > This functionality has become key for my configuration.  I've done
> some
> >>> > digging today.  Here's what I know.
> >>> >
> >>> > b2b_entities' auth call gets to around line 347 of usr_avp.c and
> fails:
> >>> >
> >>> >                 if (*crt_avps==0)
> >>> >                         return 0;
> >>> >
> >>> > Programming is not my strength.  Any thoughts what might cause this
> >>> > condition, or how it might be related b2b_entities' ability to
> process
> >>> > an
> >>> > auth request?
> >>> >
> >>> >
> >>> > - Jeff
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle <jpyle at fidelityvoice.com>
> >>> > wrote:
> >>> >>
> >>> >> Hi Ovidiu,
> >>> >>
> >>> >> It does not.  At least not for me.  Here are some snippets of my
> >>> >> config
> >>> >> file:
> >>> >>
> >>> >> modparam("uac_auth","auth_realm_avp",  "$avp(auth_realm)")
> >>> >> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> >>> >> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> >>> >>
> >>> >>
> >>> >>
> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
> >>> >>
> >>> >> route {
> >>> >>
> >>> >>   ... sanity checks, etc ...
> >>> >>
> >>> >>         $avp(auth_realm) := "appropriate-realm";
> >>> >>         $avp(auth_user)  := "valid-username";
> >>> >>         $avp(auth_pass)  := "valid-password";
> >>> >>
> >>> >>         if !(b2b_init_request("top hiding/t105")) {
> >>> >>                 xlog("L_ERR", "** b2b_init  failed - - S=$si:$sp
> T=$tU
> >>> >> F=$fU C=$ci\n");
> >>> >>                 send_reply("500", "Internal Server Error");
> >>> >>         }
> >>> >>         exit;
> >>> >> }
> >>> >>
> >>> >>
> >>> >> Configured like this, the 407 gets passed back to the client.  If I
> >>> >> uncomment the 'credential' modparam, the B2B will send an INVITE
> with
> >>> >> the
> >>> >> correct auth.
> >>> >>
> >>> >> The same uac_auth config with the same AVPs work correctly if I use
> >>> >> uac_auth() on a failure_route in a pure proxy config.  That's why
> I'm
> >>> >> confused about it not working with the B2B.  I looked through the
> >>> >> source and
> >>> >> as best I can tell the same functions are called the same way for
> >>> >> each.
> >>> >>
> >>> >> Ok, let me be specific on that last point.  The client to this B2B
> >>> >> instance is another Opensips instance with proxy-only commands, most
> >>> >> notably
> >>> >> rtpproxy.  That's where I have uac_auth() working today.  With that
> I
> >>> >> call
> >>> >> the scenario here as "top hiding/at105" (note the "a") to
> >>> >> intentionally pass
> >>> >> the 407 back to the proxy config.  It works.  Ideally, I'd prefer
> the
> >>> >> B2B
> >>> >> scenario here field the 407.
> >>> >>
> >>> >>
> >>> >> - Jeff
> >>> >>
> >>> >>
> >>> >> On Wed, Nov 13, 2013 at 4:34 PM, Ovidiu Sas <osas at voipembedded.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> If you set the AVPs before creating the b2b call, it should work on
> >>> >>> 1.10.
> >>> >>>
> >>> >>> Regards,
> >>> >>> Ovidiu Sas
> >>> >>>
> >>> >>> On Tue, Nov 12, 2013 at 11:16 PM, Jeff Pyle <
> jpyle at fidelityvoice.com>
> >>> >>> wrote:
> >>> >>> > I was about to let this one go when I found "B2B module gets
> >>> >>> > visibility
> >>> >>> > to
> >>> >>> > credentials defined via AVPs" on the About Version 1.10 page.  In
> >>> >>> > my
> >>> >>> > case it
> >>> >>> > works only if I define the 'credential' modparam for uac_auth.
> >>> >>> >
> >>
> >>
> >>
> >> --
> >> VoIP Embedded, Inc.
> >> http://www.voipembedded.com
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> 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/20131119/023b6159/attachment-0001.htm>


More information about the Users mailing list