FW: TTLS and PAP

classic Classic list List threaded Threaded
6 messages Options
| Threaded
Open this post in threaded view
|

FW: TTLS and PAP

martin.p.bradley
Folks,

I'm trying to get TTLS/PAP working using freeradius 1.0.4.  I must have
it configured incorrectly because its giving a Segmentation fault just
before giving the Access-Accept & EAP-Success back to the switch.  I
have searched the archives for a solution but not found help to sort my
problem out.

I have played around with the configuration but don't fully understand
what I'm doing.  Could someone point me to a place where I can read and
understand how the authenticate and autorize sections work.  The
explanation in the radiusd.conf file don't seem to click with me.  


I don't understand is why the modcall[authorise] appear often in request
processing before modcall[authenticate].  I thought the order was to
authenticate a user and then once we are sure they are who they say they
are then we authorise them to use the network.


Thanks for any help,
Martin.


radiusd.conf ................

authenticate {
        Auth-Type PAP {
                pap
        }
        eap
}

authorize {
        preprocess
        eap
        files

}

Users file......................

"Client certificate" Auth-Type := Local, User-Password == "bradley"
        Service-Type = Framed-User,
        Framed-Compression = Van-Jacobsen-TCP-IP


  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 3
  modcall[authorize]: module "preprocess" returns ok for request 3
    users: Matched entry DEFAULT at line 162
  modcall[authorize]: module "files" returns ok for request 3
  rlm_eap: EAP packet type response id 34 length 200
  rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
  modcall[authorize]: module "eap" returns updated for request 3
modcall: group authorize returns updated for request 3
  rad_check_password:  Found Auth-Type System
  rad_check_password:  Found Auth-Type EAP
Warning:  Found 2 auth-types on request for user 'anonymous'
auth: type "EAP"
  Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 3
  rlm_eap: Request found, released from the list
  rlm_eap: EAP/ttls
  rlm_eap: processing type ttls
  rlm_eap_ttls: Authenticate
  rlm_eap_tls: processing TLS
rlm_eap_tls:  Length Included
  eaptls_verify returned 11
    TLS_accept: SSLv3 read client key exchange A
    TLS_accept: SSLv3 read finished A
    TLS_accept: SSLv3 write change cipher spec A
    TLS_accept: SSLv3 write finished A
    TLS_accept: SSLv3 flush data
    (other): SSL negotiation finished successfully
SSL Connection Established
  eaptls_process returned 13
  modcall[authenticate]: module "eap" returns handled for request 3
modcall: group authenticate returns handled for request 3
Sending Access-Challenge of id 34 to 10.230.199.248:1126
        EAP-Message =
0x0123003d15800000003314030100010116030100288b7a33f454f760f4cddff2f95941
b215a6f3d73b5e422d1744b2201bee31448f10dc78f33f354476
        Message-Authenticator = 0x00000000000000000000000000000000
        State = 0x49b28c5e2307f384db00487f11336474
Going to the next request
Waking up in 5 seconds...
rad_recv: Access-Request packet from host 10.230.199.248:1126, id=35,
length=248
        User-Name = "anonymous"
        NAS-IP-Address = 10.230.199.248
        NAS-Port = 2
        State = 0x49b28c5e2307f384db00487f11336474
        Calling-Station-Id = "00:06:5b:d6:ff:24"
        NAS-Identifier = "radius-netgear"
        NAS-Port-Type = Ethernet
        EAP-Message =
0x02230078150017030100189e2c7d7fea093fe36d2ad301f92cc2ef4cba50563b00a0a8
1703010050b5955c43a5cd51375cebde00ed386a2f4273385aa3f6b0b2c6f7e15b73a75e
e8f64e15abdca0a875fd3408d3ce811a76580cee45fc540215f84bcc2f99a95cc5199a36
da952c0a76243f7f7645f4327b
        Message-Authenticator = 0x3ddd5d8d65f10f4a26c7db7ab52a96db
        X-Ascend-Token-Idle = 1
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 4
  modcall[authorize]: module "preprocess" returns ok for request 4
    users: Matched entry DEFAULT at line 162
  modcall[authorize]: module "files" returns ok for request 4
  rlm_eap: EAP packet type response id 35 length 120
  rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
  modcall[authorize]: module "eap" returns updated for request 4
modcall: group authorize returns updated for request 4
  rad_check_password:  Found Auth-Type System
  rad_check_password:  Found Auth-Type EAP
Warning:  Found 2 auth-types on request for user 'anonymous'
auth: type "EAP"
  Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 4
  rlm_eap: Request found, released from the list
  rlm_eap: EAP/ttls
  rlm_eap: processing type ttls
  rlm_eap_ttls: Authenticate
  rlm_eap_tls: processing TLS
  eaptls_verify returned 7
  rlm_eap_tls: Done initial handshake
  eaptls_process returned 7
  rlm_eap_ttls: Session established.  Proceeding to decode tunneled
attributes.
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 4
  modcall[authorize]: module "preprocess" returns ok for request 4
    users: Matched entry Client certificate at line 90
  modcall[authorize]: module "files" returns ok for request 4
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module "eap" returns noop for request 4
modcall: group authorize returns ok for request 4
auth: type Local
auth: user supplied User-Password matches local User-Password
  TTLS: Got tunneled Access-Accept
Segmentation fault
[root@mars raddb]#

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: FW: TTLS and PAP

Alan DeKok
<[hidden email]> wrote:
> I'm trying to get TTLS/PAP working using freeradius 1.0.4.  I must have
> it configured incorrectly because its giving a Segmentation fault just
> before giving the Access-Accept & EAP-Success back to the switch.  I
> have searched the archives for a solution but not found help to sort my
> problem out.

  See doc/bugs

> I don't understand is why the modcall[authorise] appear often in request
> processing before modcall[authenticate].  I thought the order was to
> authenticate a user and then once we are sure they are who they say they
> are then we authorise them to use the network.

  Due to historical issues, FreeRADIUS has pre-authenticate,
authenticate, and post-authenticate.  The pre-authenticate is called
"authorize".

  The sections could just as easily be called "foo", "bar", and "baz".
It makes no difference to the operation of the server.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

RE: FW: TTLS and PAP

martin.p.bradley
In reply to this post by martin.p.bradley
Alan,

Sorry about duplicating my original email.  I found your reply about 3
seconds after doing that.

Here is the stack trace.

Maybe my version of ssl is too old?

[mbradley@mars bin]$ openssl
OpenSSL> version
OpenSSL 0.9.7b 10 Apr 2003



#0  0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08,
s=0x8157790, prf_label=0x402da5d9 "ttls keying material") at
mppe_keys.c:136
136             memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE);
(gdb) bt
#0  0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08,
s=0x8157790, prf_label=0x402da5d9 "ttls keying material") at
mppe_keys.c:136
#1  0x402d8912 in eapttls_authenticate (arg=0x814dcb0,
handler=0x81576e8) at rlm_eap_ttls.c:253
#2  0x4002a627 in eaptype_call (atype=0x814dba0, handler=0x81576e8) at
eap.c:167
#3  0x4002a9f5 in eaptype_select (inst=0x810fe60, handler=0x81576e8) at
eap.c:353
#4  0x40029d89 in eap_authenticate (instance=0x810fe60,
request=0x8179b38) at rlm_eap.c:271
#5  0x08054c7a in call_modsingle (component=0, sp=0x810ebe8,
request=0x8179b38, default_result=0) at modcall.c:219
#6  0x08054e6e in modcall (component=0, c=0x810ebe8, request=0x8179b38)
at modcall.c:344
#7  0x08054d37 in call_modgroup (component=0, g=0x814f3e0,
request=0x8179b38, default_result=0) at modcall.c:252
#8  0x08054e1d in modcall (component=0, c=0x814f3e0, request=0x8179b38)
at modcall.c:335
#9  0x0805492b in module_authenticate (auth_type=6, request=0x8179b38)
at modules.c:891
#10 0x0805198b in rad_check_password (request=0x8179b38) at auth.c:353
#11 0x08051d53 in rad_authenticate (request=0x8179b38) at auth.c:644
#12 0x0804d5a9 in rad_respond (request=0x8179b38, fun=0x8051a9c
<rad_authenticate>) at radiusd.c:1642
#13 0x0804d2ea in main (argc=2, argv=0xbffff514) at radiusd.c:1427
#14 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6







123     void eaptls_gen_mppe_keys(VALUE_PAIR **reply_vps, SSL *s,
124                               const char *prf_label)
125     {
126             unsigned char out[2*EAPTLS_MPPE_KEY_LEN],
buf[2*EAPTLS_MPPE_KEY_LEN];
127             unsigned char seed[64 + 2*SSL3_RANDOM_SIZE];
(gdb) l
128             unsigned char *p = seed;
129             size_t prf_size;
130
131             prf_size = strlen(prf_label);
132
133             memcpy(p, prf_label, prf_size);
134             p += prf_size;
135
136             memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE);
137             p += SSL3_RANDOM_SIZE;
(gdb) print s
$2 = (SSL *) 0x8157790
(gdb) print s->s3
$3 = (struct ssl3_state_st *) 0x0


Regards,
Martin.















-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Alan
DeKok
Sent: 19 July 2005 20:01
To: FreeRadius users mailing list
Subject: Re: FW: TTLS and PAP

<[hidden email]> wrote:
> I'm trying to get TTLS/PAP working using freeradius 1.0.4.  I must
have
> it configured incorrectly because its giving a Segmentation fault just
> before giving the Access-Accept & EAP-Success back to the switch.  I
> have searched the archives for a solution but not found help to sort
my
> problem out.

  See doc/bugs

> I don't understand is why the modcall[authorise] appear often in
request
> processing before modcall[authenticate].  I thought the order was to
> authenticate a user and then once we are sure they are who they say
they
> are then we authorise them to use the network.

  Due to historical issues, FreeRADIUS has pre-authenticate,
authenticate, and post-authenticate.  The pre-authenticate is called
"authorize".

  The sections could just as easily be called "foo", "bar", and "baz".
It makes no difference to the operation of the server.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: FW: TTLS and PAP

Alan DeKok
<[hidden email]> wrote:
> Here is the stack trace.
>
> Maybe my version of ssl is too old?

  Maybe.

> #0  0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08,
> s=0x8157790, prf_label=0x402da5d9 "ttls keying material") at
> mppe_keys.c:136
> 136             memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE);

  TRhat doesn't tell me much, unfortunately.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Cisco auth-proxy and cisco-avpair proxyacl

Andrea.DAlessandro

Hi there,
I am running FreeRADIUS Version 1.0.4 on Solaris 8 for RADIUS services.

Then I have a Cisco 3660 configured for inbound https auth-proxy. IOS on router -> c3660-ik9o3s-mz.123-14.T.bin


% users

<snip>

#

test  Auth-Type := Local, User-Password == "test1234"

     Service-Type = Outbound,

     cisco-avpair = "auth-proxy:priv-lvl=15",

     cisco-avpair += "auth-proxy:proxyacl#1=permit tcp host 12.13.14.15 host 21.31.41.51 eq 22"

#



Problem: user test get successful auth-prox authorization but the dynamic acl is not used by the router.

FYI - The RADIUS server passes the ACL and he router receives the ACL (debug not reported in this email).


Can you help me? Thanks a lot.


Full debug on the server:


# radiusd -X

<snip>

rad_recv: Access-Request packet from host 131.176.131.40:1645, id=23, length=102

       User-Name = "test"

       Reply-Message = "Password: "

       User-Password = "test1234"

       NAS-Port = 226

       NAS-Port-Id = "tty226"

       NAS-Port-Type = Virtual

       Calling-Station-Id = "xx.xx.xx.xx"

       NAS-IP-Address = xx.xx.xx.xx

 Processing the authorize section of radiusd.conf

modcall: entering group authorize for request 0

 modcall[authorize]: module "preprocess" returns ok for request 0

 modcall[authorize]: module "chap" returns noop for request 0

 modcall[authorize]: module "mschap" returns noop for request 0

   rlm_realm: No '@' in User-Name = "adalessa", looking up realm NULL

   rlm_realm: No such realm "NULL"

 modcall[authorize]: module "suffix" returns noop for request 0

 rlm_eap: No EAP-Message, not doing EAP

 modcall[authorize]: module "eap" returns noop for request 0

   users: Matched entry adalessa at line 98

 modcall[authorize]: module "files" returns ok for request 0

modcall: group authorize returns ok for request 0

 rad_check_password:  Found Auth-Type Local

auth: type Local

auth: user supplied User-Password matches local User-Password

Sending Access-Accept of id 23 to xx.xx.xx.xx:1645

       Cisco-AVPair = "auth-proxy:priv-lvl=15"

       Cisco-AVPair += "auth-proxy:proxyacl#1=permit tcp host 12.13.14.15 host 21.31.41.51 eq 22"

Finished request 0

Going to the next request

--- Walking the entire request list ---

Waking up in 6 seconds...

--- Walking the entire request list ---

Cleaning up request 0 ID 23 with timestamp 42dea17c

Nothing to do.  Sleeping until we see a request.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Cisco auth-proxy and cisco-avpair proxyacl

Alan DeKok
[hidden email] wrote:
> Problem: user test get successful auth-prox authorization but the dynamic
> acl is not used by the router.
> FYI - The RADIUS server passes the ACL and he router receives the ACL
> (debug not reported in this email).

  Then the router is broken.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html