[Serusers] Password not being sent during Radius Auth

Greger V. Teigre greger at teigre.com
Wed Apr 13 06:59:50 CEST 2005


See inline.
Lucas Aimaretto wrote:
>>> The thing is that I'm not seeing the Password Attribute at
>>> the radius output ...
>
>> Lucas,
>> Your RADIUS server needs to implement the Digest algorithm.
>> Attributes are
>> non-standard and are NOT sent as vendor-encapsulated, but
>> wrapped in the
>> Digest-Attributes avpair.  The RADIUS server thus needs to be
>> able to read
>> the digest-attributes, convert them to individual attributes
>> (as below) and
>> then implement the DIGEST authentication mechanism.
>>     Translated: There is no password attribute.
>> g-)
>>
>> ATTRIBUTE       Digest-Response                 206     string
>> ATTRIBUTE       Digest-Attributes               207     string
>> ATTRIBUTE       Digest-Realm                    1063    string
>> ATTRIBUTE       Digest-Nonce                    1064    string
>> ATTRIBUTE       Digest-Method                   1065    string
>> ATTRIBUTE       Digest-URI                      1066    string
>> ATTRIBUTE       Digest-QOP                      1067    string
>> ATTRIBUTE       Digest-Algorithm                1068    string
>> ATTRIBUTE       Digest-Body-Digest              1069    string
>> ATTRIBUTE       Digest-CNonce                   1070    string
>> ATTRIBUTE       Digest-Nonce-Count              1071    string
>> ATTRIBUTE       Digest-User-Name                1072    string
>
> Ok, thanx for the answer. Anyways, I think I'll need a little help
> with this. I already loaded those attributes into my dictionary, both
> dictionary.ser and dictionary.sip. Now, If I have no password assigned
> to my user, Users can authenticate with no problems at all. Now, if I
> assign password, I see the following ...
>
> RADIUS OUTPUT:
>
> radrecv: Access Request from host c0a801fd code=1, id=158, length=271
>    User-Name = "1991006 at 192.168.1.253"
>    Digest-Attributes = "\012\0111991006"
>    Digest-Attributes = "\001\017192.168.1.253"
>    Digest-Attributes = "\002*425bde0ae10d15c59c4e3a5c45288ed4175a8a2a"
>    Digest-Attributes = "\004\023sip:192.168.1.253"
>    Digest-Attributes = "\003\012REGISTER"
>    Digest-Response = "a341b3fdbacc4747b82e0718b31e627c"
>    Service-Type = Sip-Session
>    Sip-URI-User = "1991006"
>    Unknown-Attr-327681 =
> "call-id=EAED054A3CA3478184AA441574592609 at 192.168.1.253"
>    NAS-IP-Address = 192.168.1.253
>    NAS-Port-Id = 5060
> SQL: Attempting to reserve socket
> SQL: Reserved socket 0
> Username is now 1991006
> Calling station Id is now 1991006
> Calling station Id is now (null)
> Sending Access Reject of id 158 to c0a801fd (nas linux)
>  Se envio Auth Reject
> SQL: Socket 0 used for 0.61 seconds
> SQL: Released socket 0
>
> SER OUTPUT:
>
> 0(17666) get_hdr_field: cseq <CSeq>: <27392> <REGISTER>
> 0(17666) DEBUG: is_maxfwd_present: value = 70
> 0(17666) end of header reached, state=9
> 0(17666) parse_headers: flags=256
> 0(17666) DEBUG: get_hdr_body : content_length=0
> 0(17666) found end of header
> 0(17666) find_first_route(): No Route headers found
> 0(17666) loose_route(): There is no Route HF
> 0(17666) check_self - checking if host==us: 13==13 &&  [192.168.1.253]
> == [192.168.1.253]
> 0(17666) check_self - checking if port 5060 matches port 5060
> 0(17666) check_nonce(): comparing
> [425bde0ae10d15c59c4e3a5c45288ed4175a8a2a] and
> [425bde0ae10d15c59c4e3a5c45288ed4175a8a2a]
> 0(17666) res: -2
> 0(17666) radius_authorize_sterman(): Failure
> 0(17666) build_auth_hf(): 'WWW-Authenticate: Digest
> realm="192.168.1.253",
> nonce="425bde0ae10d15c59c4e3a5c45288ed4175a8a2a"' 0(17666)
> parse_headers: flags=-1 0(17666) check_via_address(192.168.1.178,
> 192.168.1.178, 0) 0(17666) DEBUG:destroy_avp_list: destroing list
> (nil) 0(17666) receive_msg: cleaning up
>
> Now, these are the questions:
>
> 1) What my radius is receiving, looks fine ?
This might confuse the radius server. Except from that, it looks ok.
  Unknown-Attr-327681 =
"call-id=EAED054A3CA3478184AA441574592609 at 192.168.1.253"

> 2) What must my radius be capable of doing to authenticate users with
> password ? I know you said it must resolve digest attributes, but,
> what does it mean ? ( or please give me some place where to read
> something ).

Well, do you want the RFC?  ;-) (search for http digest) It's more an 
implementation issue.

3) I know my radius supports CHAP-MD5. Isn't it enough ?
Nope. Digest as another algorithm than CHAP that can use MD5 too

>
> The thing is I've using this radius for some time now, and have
> modified it to help my needs. I know it's a bit old already (2002).
> Its ic-radius and, according to its web page it does support digest.
> I think ...

Well, it must both support digest and the bit special way the 
*-digest-attritbutes are wrapped into the Digest-Attributes attribute.
I don't know ic-radius.  We have implemented digest for our own (commercial) 
RADIUS server.
freeRADIUS is your best bet, or the support forum for ic-radius.

g-) 




More information about the sr-users mailing list