[sr-dev] auth apis & radius
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Jun 14 15:16:12 CEST 2010
Andrei!
Is it possible to use modules_s/auth as a replacement for
modules_k/auth? Are they compatible from user point of view?
regards
Klaus
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
More information about the sr-dev
mailing list