[sr-dev] auth apis & radius

[Andrei Pelinescu-Onciul]

On Jun 14, 2010 at 15:16, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Andrei!
> 
> Is it possible to use modules_s/auth as a replacement for
> modules_k/auth? Are they compatible from user point of view?

In ser the auth module is used more like a "library" (other modules use
it via auth_api). It has only 1 script function: consume_credentials().
In kamailio besides the api interface, it exports more script functions
(which seem to be simple wrappers over the already exported api
functions, so they would be easiy to add to auth(s) too).

Andrei

> Am 14.06.2010 13:58, schrieb Andrei Pelinescu-Onciul:
> >[cc'ed sr-dev]
> >
> >On Jun 13, 2010 at 11:10, Juha Heinanen<jh at tutpro.com>  wrote:
> >>Dmitry Kirillov writes:
> >>
> >>>Program received signal SIGSEGV, Segmentation fault.
> >>>0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
> >>>(gdb) bt
> >>>#0 0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
> >>>#1 0x28816555 in authorize (_msg=0x8343b58, _realm=0x0, _uri_user=0x0,
> >>>_hftype=15) at authorize.c:102
> >>>#2 0x288163e8 in radius_proxy_authorize_1 (_msg=0x8343b58, _realm=0x0,
> >>>_s2=0x0) at authorize.c:157
> >>
> >>i'm not sure what is going on.  looks like you are using s version of
> >>auth module, but there pre_auth has five params:
> >>
> >>auth_result_t pre_auth(struct sip_msg* msg, str* realm, hdr_types_t hftype,
> >>						struct hdr_field**  hdr, check_auth_hdr_t check_auth_hdr)
> >>
> >>whereas the above seems to indicate that k version of auth module is in
> >>use where pre_auth has four params:
> >>
> >>auth_result_t pre_auth(struct sip_msg* _m, str* _realm, hdr_types_t _hftype,
> >>					struct hdr_field** _h)
> >
> >It looks like he uses modules/auth_radius (which seems to be the k
> >version) and modules_s/auth. Unfortunately the ser auth api is
> >incompatible with the k one.
> >OTOH IMHO the ser auth module is superior to the k one, e.g.:
> >  ser auth:
> >  + nonce-count/qop=auth* support:
> >    http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.html#nonce_count
> >  + lockless in nonce-count or one time nonce mode
> >  + extra protection even in non qop=auth mode and non-one-time-nonce mode
> >   (the one time nonce mode has potential issues with retransmissions):
> >   http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.html#auth.auth_checks
> >  + speed optimized (less syscalls, concurrent access)
> >  + base64 nonces (shorter)
> >
> >  k auth (at first sight) seems to support only on-time-nonces and their
> >  implementation uses locks (and seems to be more "limited").
> >>
> >>anyway, i only have experience with kamailio_3.0 radius auth, which has
> >>worked fine.  perhaps you can try with that too.
> >
> >
> >We need either to quickly merge the auth apis or revive
> >modules_s/auth_radius (and probably the other modules_s/*radius).
> >Unfortunately merging the auth api doesn't look like a quick job:
> >ser auth api:
> >  + build_challenge()
> >  + qop
> >  + calc_response()
> >k auth api:
> >  + rpid_avp
> >  + rpid_avp_type
> >  + check_response()
> >
> >so reviving the modules_s/*radius looks like the quick fix (at least
> >for 3.0).
> >So anybody against reviving them in 3.0? (or does anybody remember any
> >problem with the s versions?)
> >
> >
> >Andrei
> >
> >_______________________________________________
> >sr-dev mailing list
> >sr-dev at lists.sip-router.org
> >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev