16 Nov
2004
16 Nov
'04
11:39 p.m.
Hello everyone,
I've succesfully compiled and installed SER 0.8.14 on a redhat 7.3.
Got an Xlite and a Grandstream Budgetone-100 registered and they both
could communicate between them.
Now, I want to use RADIUS with SER. I got SER compiled with RADIUS
support, and also compiled the radiusclient 0.4.3, and it seems
everything went fine.
I added both dictionary.ser and dictionary.sip to my dictionary, and I
believe there is something wrong here.
I followed the instrucitions at the RADIUS-HOWTO ...
1) touch digest
2) echo User-Name = "110(a)192.168.1.253".253", Digest-Response =
"631d6d73147add2f9e437f59bbc3aeb7", Digest-Realm = "testrealm",
Digest-Nonce = "1234abcd" , Digest-Method = "INVITE", Digest-URI =
"sip:5555551212@example.com", Digest-Algorithm = "MD5",
Digest-User-Name
= "110(a)192.168.1.253" > digest
3) radclient -f digest localhost auth radiussecret
... And this is the RADIUS OUTPUT ...
radrecv: Access Request from host c0a801fd code=1, id=86, length=174
User-Name = "1992005(a)192.168.1.253"
Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7"
Digest-Attributes = "\001\013testrealm"
Digest-Attributes = "\002\0121234abcd"
Digest-Attributes = "\003\010INVITE"
Digest-Attributes = "\004\034sip:5555551212@example.com"
Digest-Attributes = "\006\005MD5"
Digest-Attributes = "\012\0271992005(a)192.168.1.253"
Username is now 1992005(a)192.168.1.253
Calling station Id is now (null)
Client 1992005(a)192.168.1.253 is PREPAID
credit_amount (19.00)
Sending Access Ack of id 86 to c0a801fd (nas linux)
Credit-Amount =
"V9:T102:L26:683332332d6372656469742d616d6f756e743d31392e3030"
... And this is the radclient OUTPUT ...
Received response ID 86, code 2, length = 52
Vendor-9-Attr-102 =
0x683332332d6372656469742d616d6f756e743d31392e3030
Questions:
1) Although I sent to radius diferent ATTRIBUTES, RADIUS recognized all
of them (except for one, Digest-Response) as Digest-Attributes. Why is
that?
2) All of the values sent to RADIUS, for each attribute, are different
from the ones originally sent. For example ...
sent: Digest-Method = "INVITE"
received: Digest-Attributes = "\003\010INVITE"
So you see the "\003\010" chars in front of the string "INVITE"
... Why is that?
Well, I hope you can clarify some (better if all of them ;-) ) of my
doubts.
Thanx in advance
Regards,
Lucas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 29/10/2004
16 Nov
16 Nov
11:19 p.m.
Hi
I'm playing with this right now, so I'll try to comment a bit
Lucas Aimaretto wrote:
... And this is the radclient OUTPUT ...
Received response ID 86, code 2, length = 52
Vendor-9-Attr-102 =
0x683332332d6372656469742d616d6f756e743d31392e3030
the correct response should be
Login OK: [test] (from client localhost port 0)
Sending Access-Accept of id 188 to 127.0.0.1:32769
Reply-Message = "Hello, test with digest"
if I recall correctly, IC-RADIUS is based on Cistron
RADIUS. Cistron RADIUS don't have digest auth support,
and it seems never will. Cistron's author recommend
to use FreeRADIUS instead, which has the Digest
support and correctly give the result shown above
so... I drop my Cistron RADIUS and installed FreeRADIUS
to see how it behave on my test server
Questions:
1) Although I sent to radius diferent ATTRIBUTES, RADIUS recognized all
of them (except for one, Digest-Response) as Digest-Attributes. Why is
that?
may be because IC-RADIUS doesn't have digest support?
2) All of the values sent to RADIUS, for each
attribute, are different
from the ones originally sent. For example ...
sent: Digest-Method = "INVITE"
received: Digest-Attributes = "\003\010INVITE"
So you see the "\003\010" chars in front of the string "INVITE"
... Why is that?
I also noticed that with FreeRADIUS. no clue on this one
Well, I hope you can clarify some (better if all of
them ;-) )
of my doubts.
one thing I could not find was an example ser.cfg that logs
the calls via RADIUS. All posts I found tend to guide to
http://www.iptel.org/ser/doc/modules/html/acc.html
but I'm far new to SER to be able to convert the man page
on a working example ;-)
I'm using pretty much the etc/nathelper.cfg example config
on my tests.
hope this helps
Cheers
!3runo
17 Nov
17 Nov
1:22 a.m.
Bruno,
Firstly, thanx for answering ...
I don't think digest support has to do with the attributes not being
recognized. I think it is something else ... But do not know what is it.
And I believe icradius supports digest auth, cause I made a test ... I
called from user 1992005 to user 1992003 ... Radius authenticated user
1992005 and called was established, so, SER also understood RADIUS
respones ... Look at radius output ...
radrecv: Access Request from host c0a801fd code=1, id=17, length=215
User-Name = "1992005(a)192.168.1.253"
Digest-Attributes = "\012\0111992005"
Digest-Attributes = "\001\017192.168.1.253"
Digest-Attributes = "\002*419a7a30c9fe08ae43336232e7b687fb633edbd6"
Digest-Attributes = "\004\033sip:1992003@192.168.1.253"
Digest-Attributes = "\003\010INVITE"
Digest-Response = "afae2bb3cf9dfb3a3d2dd10f5fd29132"
Service-Type = Sip-Session
Sip-Uri-User = "1992005"
NAS-IP-Address = 192.168.1.253
NAS-Port-Id = 5060
Username is now 1992005(a)192.168.1.253
Calling station Id is now (null)
credit_amount (19.00)
Sending Access Ack of id 17 to c0a801fd (nas linux)
Credit-Amount =
"V9:T102:L26:683332332d6372656469742d616d6f756e743d31392e3030"
Sending Access Accept of id 17 to c0a801b2 (nas lucas)
SQL: Socket 0 used for 0.75 seconds
SQL: Released socket 0
The thing here is why some attributes are recognized and other not. For
example: digest-respones, Sip-Uri-user (which are new attributes that I
added myself to the general dictionary, and got them from the
dictionary.ser) and are recognized. Some others not (digest-realm,
digest-nonce, etc, taken out from the same dictionary.ser) and are only
recognized as Digest-Attributes ... :S ... No idea ...
Any ideas ???
I'm playing with this right now, so I'll try
to comment a bit
Lucas Aimaretto wrote:
You know, after searching at
http://icradius.sourceforge.net/modules.php?name=Web_Links&l_op=viewlink
&cid=7 found that ...
"Description: icradius "REQUIRES" the following Perl Modules all of
which are available at the link above:
- Authen::RADIUS
- Digest::MD5
- Date::Calc
- Bit::Vector
- DBI
- DBD::mysql"
... So I believe, Icradius does support digest Authentication. In fact,
I have an utility for radius testing called NT-RADPING (really cool!!)
and did a test again user 1992005 ... Whatch out the RADIUS OUTPUT and
look at the CHAP-Password attribute ...
radrecv: Access Request from host c0a801b2 code=1, id=1, length=62
User-Name = "110"
CHAP-Password = "xt\265\256ohy\257xY\034\214x_X$\277"
Username is now 110
Calling station Id is now (null)
credit_amount (215.49)
Sending Access Ack of id 1 to c0a801b2 (nas lucas)
Credit-Amount =
"V9:T102:L27:683332332d6372656469742d616d6f756e743d3231352e3439"
Sending Access Accept of id 1 to c0a801b2 (nas lucas)
SQL: Socket 0 used for 0.48 seconds
SQL: Released socket 0
So you see, that I got an access-accept. In the utility I wrote down the
password as plain-text, but you see, at the radius output it is
encrypted.
... And this is the radclient OUTPUT ...
Received response ID 86, code 2, length = 52
Vendor-9-Attr-102 =
0x683332332d6372656469742d616d6f756e743d31392e3030
the correct response should be
Login OK: [test] (from client localhost port 0)
Sending Access-Accept of id 188 to 127.0.0.1:32769
Reply-Message = "Hello, test with digest"
if I recall correctly, IC-RADIUS is based on Cistron
RADIUS. Cistron RADIUS don't have digest auth support,
and it seems never will. Cistron's author recommend
to use FreeRADIUS instead, which has the Digest
support and correctly give the result shown above Questions:
1) Although I sent to radius diferent ATTRIBUTES, RADIUS recognized
all of them (except for one, Digest-Response) as Digest-Attributes.
Why is that?
may be because IC-RADIUS doesn't have digest support? hope this helps
Thanx!
Cheers
Regards,
!3runo
Lucas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 29/10/2004
1:38 a.m.
Hi
Interesting to know that ICRADIUS can do Digest.
try to include both dictionary.ser (from SER) and
dictionary.sip (from radiusclient) on ICRADIUS
dictionary
the first didn't work with with Cistron RADIUS
but worked with FreeRADIUS. YMMV
Cheers
!3runo
Lucas Aimaretto wrote:
I don't think digest support has to do with the attributes not being
recognized. I think it is something else ... But do not know what is it. [...]
... So I believe, Icradius does support digest
Authentication. In fact,
I have an utility for radius testing called NT-RADPING (really cool!!)
and did a test again user 1992005 ...
[...]
1) Although I sent to radius diferent ATTRIBUTES,
RADIUS recognized
all of them (except for one, Digest-Response) as Digest-Attributes.
Why is that?
may be because IC-RADIUS doesn't have digest support? The thing here is why some attributes are recognized
and other not. For
example: digest-respones, Sip-Uri-user (which are new attributes that I
added myself to the general dictionary, and got them from the
dictionary.ser) and are recognized. Some others not (digest-realm,
digest-nonce, etc, taken out from the same dictionary.ser) and are only
recognized as Digest-Attributes ... :S ... No idea ...
7:45 p.m.
Bruno,
> > >1) Although I sent to radius diferent
ATTRIBUTES, RADIUS
recognized
> > >all of them (except for one,
Digest-Response) as
Digest-Attributes.
> > >Why is that?
> >may be because IC-RADIUS doesn't have
digest support?
> I don't think digest support has to do with
the attributes not being
> recognized. I think it is something else ... But
do not know what is
> it.
[...]
> The thing here is why some attributes are
recognized and others not.
> For
> example: digest-respones, Sip-Uri-user (which are new
> attributes that I
> added myself to the general dictionary, and got them from the
> dictionary.ser) are recognized. Some others not (digest-realm,
> digest-nonce, etc, taken out from the same dictionary.ser)
> and are only recognized as Digest-Attributes ... :S ... No idea ...
try to include both dictionary.ser (from SER) and
dictionary.sip (from radiusclient) on ICRADIUS dictionary
the first didn't work with with Cistron RADIUS
but worked with FreeRADIUS. YMMV
I did, but nothing new happened ...
I added both dictionary.ser and dictionary.sip but nothin happened at
all :(
In fact, I deleted the whole dictionary, and started all over again, but
no new behaviour at all ...
It just makes no sense ... Why would some attributes be recognized and
some others not. It is not logical, as they are all (the attributes)
taken from the same files (dictionary.sip and dictionary.ser).
Is there any special configuration needed for the ser.cfg or for the
radiusclient.conf ? The radius.conf file of my icradius has little to
touch ... Any ideas ??
I'll keep trying and seraching so to try to find a solution for this ...
In the meanwhile, if you (or anybody else) have something, please letme
know.
Thank you very much ...
Regards,
Lucas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 29/10/2004
19 Nov
19 Nov
12:03 a.m.
On 16-11 17:39, Lucas Aimaretto wrote:
Hello everyone,
I've succesfully compiled and installed SER 0.8.14 on a redhat 7.3.
Got an Xlite and a Grandstream Budgetone-100 registered and they both
could communicate between them.
Now, I want to use RADIUS with SER. I got SER compiled with RADIUS
support, and also compiled the radiusclient 0.4.3, and it seems
everything went fine.
I added both dictionary.ser and dictionary.sip to my dictionary, and I
believe there is something wrong here.
I followed the instrucitions at the RADIUS-HOWTO ...
1) touch digest
2) echo User-Name = "110(a)192.168.1.253".253", Digest-Response =
"631d6d73147add2f9e437f59bbc3aeb7", Digest-Realm = "testrealm",
Digest-Nonce = "1234abcd" , Digest-Method = "INVITE", Digest-URI =
"sip:5555551212@example.com", Digest-Algorithm = "MD5",
Digest-User-Name
= "110(a)192.168.1.253" > digest
3) radclient -f digest localhost auth radiussecret
... And this is the RADIUS OUTPUT ...
radrecv: Access Request from host c0a801fd code=1, id=86, length=174
User-Name = "1992005(a)192.168.1.253"
Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7"
Digest-Attributes = "\001\013testrealm"
Digest-Attributes = "\002\0121234abcd"
Digest-Attributes = "\003\010INVITE"
Digest-Attributes = "\004\034sip:5555551212@example.com"
Digest-Attributes = "\006\005MD5"
Digest-Attributes = "\012\0271992005(a)192.168.1.253"
Username is now 1992005(a)192.168.1.253
Calling station Id is now (null)
Client 1992005(a)192.168.1.253 is PREPAID
credit_amount (19.00)
Sending Access Ack of id 86 to c0a801fd (nas linux)
Credit-Amount =
"V9:T102:L26:683332332d6372656469742d616d6f756e743d31392e3030"
... And this is the radclient OUTPUT ...
Received response ID 86, code 2, length = 52
Vendor-9-Attr-102 =
0x683332332d6372656469742d616d6f756e743d31392e3030
Questions:
1) Although I sent to radius diferent ATTRIBUTES, RADIUS recognized all
of them (except for one, Digest-Response) as Digest-Attributes. Why is
that?
That's because they are encoded and sent as sub-attributes, not real
RADIUS attributes, see draft-sterman-aaa-sip-00 for more details.
2) All of the values sent to RADIUS, for each
attribute, are different
from the ones originally sent. For example ...
sent: Digest-Method = "INVITE"
received: Digest-Attributes = "\003\010INVITE"
So you see the "\003\010" chars in front of the string "INVITE"
... Why is that?
This is the sub-type of the atttribute, see the draft mentioned before.
Note that the radius server has to explicitely support this "attribute
mangling" (try to find out if it supports icradius server supports
draft-sterman-aaa-sip-00
Well, I hope you can clarify some (better if all of them ;-) ) of my
doubts.
In conclusion, digest authentication attributes are encoded as
sub-attributes into a single RADIUS attribute and it will work only if
the radius server explicitely supports that (according to
draft-sterman-aaa-sip-00).
Jan.
7299
days inactive
7301
days old
5 comments
3 participants
participants (3)
-
Bruno Lopes F. Cabral -
Jan Janak -
Lucas Aimaretto