[Wimax TTLS with Alcatel - Lucent ASN GW]
Hello, First thanks again for this new release that adds very interesting features for debug, specially raddebug and radmin. Using basic setup, Freeradius successfully authenticate request coming from CPE Wimax through ASN Alcatel GW (called WAC) using EAP/TTLS Fri Apr 3 01:05:10 2009 : Auth: Login OK: [00210400E0D7@test.fr/<via Auth-Type = EAP>] (from client wimax port 0 cli 00-21-04-00-E0-D7) Fri Apr 3 01:05:19 2009 : Auth: Login OK: [cpe2-lab@test.fr/<via Auth-Type = mschap>] (from client wimax port 0 via TLS tunnel) I now have 2 issues to fill properly the access accept with correct attribute. (This needs might be weird, but it is the way this ASN GW works) 1. I would like that the outer access accept contains attributes coming from the inner access accept So I tried to use the update outer.reply on post-auth section of the inner-tunnel virtual server update outer.reply { #User-Name = "%{request:User-Name}" WiMAX-Packet-Data-Flow-Id = "%{request:WiMAX-Packet-Data-Flow-Id}" } But as I understand, you can only use "request" from the inner tunnel, but not the attribute contained in the reply of the inner tunnel. Is that true ? Is there a way to do that. To be more precise this is the reply in the inner tunnel Fri Apr 3 01:13:33 2009 Packet-Type = Access-Accept WiMAX-Packet-Data-Flow-Id = 1 WiMAX-Service-Data-Flow-Id = 1 WiMAX-Service-Profile-Id = 1 WiMAX-Direction = Bi-Directional WiMAX-QoS-Id = 1 WiMAX-Media-Flow-Type = Robust-Browser WiMAX-Schedule-Type = Best-Effort WiMAX-Traffic-Priority = 0 WiMAX-Maximum-Sustained-Traffic-Rate = 512000 MS-CHAP2-Success = 0xdf533d37443041423038393133393032414333353841304630414336383132453546434243364130323046 MS-MPPE-Recv-Key = 0x1d7c9b57392b589e2849640bad969199 MS-MPPE-Send-Key = 0x4aa107e5fa9573846af44d21c5080749 MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006 and the one in the outer tunnel Fri Apr 3 01:13:34 2009 Packet-Type = Access-Accept MS-MPPE-Recv-Key = 0x6b185c55d7785700e6f52c9ae0160945476aa4ab9e5b699dc6cffb5427c06395 MS-MPPE-Send-Key = 0x009d98e233e6911f97346381a77e90d01b7d41b3aa82dbf6ce56f54bb9b2598b EAP-MSK = 0x6b185c55d7785700e6f52c9ae0160945476aa4ab9e5b699dc6cffb5427c06395009d98e233e6911f97346381a77e90d01b7d41b3aa82dbf6ce56f54bb9b2598b EAP-EMSK = 0xc5f48626093f9313c5090254ffc375d4594bf6570025a260801e4b8d0ff852167d0748bd50b27d214b0ee67c1bbe1a4395faf094a8cb56663177fa8f32586f40 EAP-Message = 0x03f00004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "00210400E0D7@test.fr" I would like the reply of the outer tunnel to contain all the Wimax Attribute I got in the inner. 2. For some weird reason again, Alcatel ASN needs to receive two times the same attribute with differente value (Actually this WiMAX-QoS-Descriptor (TLV Attribute)) I guess this is not very compliant with RFC, but is there a way to send 2 times the same attribute in the same reply. I've tried that but without surprise this send only the first part of the attribute cpe2-lab@test.fr Cleartext-Password := "xxx" WiMAX-Packet-Data-Flow-Id=1, WiMAX-Service-Data-Flow-Id=1, WiMAX-Service-Profile-Id=1, WiMAX-Direction=Bi-Directional, WiMAX-QoS-Id=01, WiMAX-Media-Flow-Type=Robust-Browser, WiMAX-Schedule-Type=BEST-EFFORT, WiMAX-Traffic-Priority=0, WiMAX-Maximum-Sustained-Traffic-Rate=512000, WiMAX-QoS-Id=02, WiMAX-Media-Flow-Type=Robust-Browser, WiMAX-Schedule-Type=BEST-EFFORT, WiMAX-Traffic-Priority=0, WiMAX-Maximum-Sustained-Traffic-Rate=512000 Maybe using perl module in the post-auth ? Thanks Thomas Fagart
Using basic setup, Freeradius successfully authenticate request coming from CPE Wimax through ASN Alcatel GW (called WAC) using EAP/TTLS
Fri Apr 3 01:05:10 2009 : Auth: Login OK: [00210400E0D7@test.fr/<via Auth-Type = EAP>] (from client wimax port 0 cli 00-21-04-00-E0-D7) Fri Apr 3 01:05:19 2009 : Auth: Login OK: [cpe2-lab@test.fr/<via Auth-Type = mschap>] (from client wimax port 0 via TLS tunnel)
I now have 2 issues to fill properly the access accept with correct attribute. (This needs might be weird, but it is the way this ASN GW works)
1. I would like that the outer access accept contains attributes coming from the inner access accept
So I tried to use the update outer.reply on post-auth section of the inner-tunnel virtual server
update outer.reply { #User-Name = "%{request:User-Name}" WiMAX-Packet-Data-Flow-Id = "%{request:WiMAX-Packet-Data-Flow-Id}" }
But as I understand, you can only use "request" from the inner tunnel, but not the attribute contained in the reply of the inner tunnel. Is that true ? Is there a way to do that.
To be more precise this is the reply in the inner tunnel
Fri Apr 3 01:13:33 2009 Packet-Type = Access-Accept WiMAX-Packet-Data-Flow-Id = 1 WiMAX-Service-Data-Flow-Id = 1 WiMAX-Service-Profile-Id = 1 WiMAX-Direction = Bi-Directional WiMAX-QoS-Id = 1 WiMAX-Media-Flow-Type = Robust-Browser WiMAX-Schedule-Type = Best-Effort WiMAX-Traffic-Priority = 0 WiMAX-Maximum-Sustained-Traffic-Rate = 512000 MS-CHAP2-Success = 0xdf533d37443041423038393133393032414333353841304630414336383132453546434243364130323046 MS-MPPE-Recv-Key = 0x1d7c9b57392b589e2849640bad969199 MS-MPPE-Send-Key = 0x4aa107e5fa9573846af44d21c5080749 MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006
and the one in the outer tunnel
Fri Apr 3 01:13:34 2009 Packet-Type = Access-Accept MS-MPPE-Recv-Key = 0x6b185c55d7785700e6f52c9ae0160945476aa4ab9e5b699dc6cffb5427c06395 MS-MPPE-Send-Key = 0x009d98e233e6911f97346381a77e90d01b7d41b3aa82dbf6ce56f54bb9b2598b EAP-MSK = 0x6b185c55d7785700e6f52c9ae0160945476aa4ab9e5b699dc6cffb5427c06395009d98e233e6911f97346381a77e90d01b7d41b3aa82dbf6ce56f54bb9b2598b EAP-EMSK = 0xc5f48626093f9313c5090254ffc375d4594bf6570025a260801e4b8d0ff852167d0748bd50b27d214b0ee67c1bbe1a4395faf094a8cb56663177fa8f32586f40 EAP-Message = 0x03f00004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "00210400E0D7@test.fr"
I would like the reply of the outer tunnel to contain all the Wimax Attribute I got in the inner.
Set use_tunneled_reply in ttls section of eap.conf.
2. For some weird reason again, Alcatel ASN needs to receive two times the same attribute with differente value (Actually this WiMAX-QoS-Descriptor (TLV Attribute)) I guess this is not very compliant with RFC, but is there a way to send 2 times the same attribute in the same reply.
I've tried that but without surprise this send only the first part of the attribute
cpe2-lab@test.fr Cleartext-Password := "xxx" WiMAX-Packet-Data-Flow-Id=1, WiMAX-Service-Data-Flow-Id=1, WiMAX-Service-Profile-Id=1, WiMAX-Direction=Bi-Directional, WiMAX-QoS-Id=01, WiMAX-Media-Flow-Type=Robust-Browser, WiMAX-Schedule-Type=BEST-EFFORT, WiMAX-Traffic-Priority=0, WiMAX-Maximum-Sustained-Traffic-Rate=512000, WiMAX-QoS-Id=02, WiMAX-Media-Flow-Type=Robust-Browser, WiMAX-Schedule-Type=BEST-EFFORT, WiMAX-Traffic-Priority=0, WiMAX-Maximum-Sustained-Traffic-Rate=512000
Maybe using perl module in the post-auth ?
Use += operator and add them twice. In whatever module you added them first time. Ivan Kalik Kalik Informatika ISP
Thanks for the hint, it works well now. I've got another question for my setup to work. I've notice using Wireshark that Freeradius will "break" the TLV Attribut into two attributes parts. For sample when I configure this in users file #ATTRIBUTE WiMAX-Packet-Flow-Descriptor 28 WiMAX-Packet-Data-Flow-Id=1, WiMAX-Service-Data-Flow-Id1, WiMAX-Direction=3, WiMAX-Transport-Type=1, WiMAX-Activation-Trigger=4, WiMAX-Uplink-QOS-Id=1, WiMAX-Downlink-QOS-Id=2, And I have a look at the capture The capture will display two times the attribute WiMAX-Packet-Flow-Descriptor (28), the firt part will contain the first 6 sub attributes, and the second part the last 4 sub attributes. I would like that all the subattribute being in one part. I've read the documentation contains in dictionary.wimax at the beginning, I've the feeling that this might be related, but I don't understand it properly. (there's a part where it talks about size limitation ?) So here are my questions 1. Is there a way to have it in one part ? 2. Is there's a way to specify the main attribute directly (instead of specifying each subattribute Something like this WiMAX-Packet-Flow-Descriptor=0x000104000102040001040303060301050304070301080302 Regards Thomas On Fri, 03 Apr 2009 01:28:32 +0100, <tnt@kalik.net> wrote:
Using basic setup, Freeradius successfully authenticate request coming from CPE Wimax through ASN Alcatel GW (called WAC) using EAP/TTLS
Fri Apr 3 01:05:10 2009 : Auth: Login OK: [00210400E0D7@test.fr/<via Auth-Type = EAP>] (from client wimax port 0 cli 00-21-04-00-E0-D7) Fri Apr 3 01:05:19 2009 : Auth: Login OK: [cpe2-lab@test.fr/<via Auth-Type = mschap>] (from client wimax port 0 via TLS tunnel)
I now have 2 issues to fill properly the access accept with correct attribute. (This needs might be weird, but it is the way this ASN GW works)
1. I would like that the outer access accept contains attributes coming from the inner access accept
So I tried to use the update outer.reply on post-auth section of the inner-tunnel virtual server
update outer.reply { #User-Name = "%{request:User-Name}" WiMAX-Packet-Data-Flow-Id = "%{request:WiMAX-Packet-Data-Flow-Id}" }
But as I understand, you can only use "request" from the inner tunnel, but not the attribute contained in the reply of the inner tunnel. Is that true ? Is there a way to do that.
To be more precise this is the reply in the inner tunnel
Fri Apr 3 01:13:33 2009 Packet-Type = Access-Accept WiMAX-Packet-Data-Flow-Id = 1 WiMAX-Service-Data-Flow-Id = 1 WiMAX-Service-Profile-Id = 1 WiMAX-Direction = Bi-Directional WiMAX-QoS-Id = 1 WiMAX-Media-Flow-Type = Robust-Browser WiMAX-Schedule-Type = Best-Effort WiMAX-Traffic-Priority = 0 WiMAX-Maximum-Sustained-Traffic-Rate = 512000 MS-CHAP2-Success = 0xdf533d37443041423038393133393032414333353841304630414336383132453546434243364130323046 MS-MPPE-Recv-Key = 0x1d7c9b57392b589e2849640bad969199 MS-MPPE-Send-Key = 0x4aa107e5fa9573846af44d21c5080749 MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006
and the one in the outer tunnel
Fri Apr 3 01:13:34 2009 Packet-Type = Access-Accept MS-MPPE-Recv-Key = 0x6b185c55d7785700e6f52c9ae0160945476aa4ab9e5b699dc6cffb5427c06395 MS-MPPE-Send-Key = 0x009d98e233e6911f97346381a77e90d01b7d41b3aa82dbf6ce56f54bb9b2598b EAP-MSK = 0x6b185c55d7785700e6f52c9ae0160945476aa4ab9e5b699dc6cffb5427c06395009d98e233e6911f97346381a77e90d01b7d41b3aa82dbf6ce56f54bb9b2598b EAP-EMSK = 0xc5f48626093f9313c5090254ffc375d4594bf6570025a260801e4b8d0ff852167d0748bd50b27d214b0ee67c1bbe1a4395faf094a8cb56663177fa8f32586f40 EAP-Message = 0x03f00004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "00210400E0D7@test.fr"
I would like the reply of the outer tunnel to contain all the Wimax Attribute I got in the inner.
Set use_tunneled_reply in ttls section of eap.conf.
2. For some weird reason again, Alcatel ASN needs to receive two times the same attribute with differente value (Actually this WiMAX-QoS-Descriptor (TLV Attribute)) I guess this is not very compliant with RFC, but is there a way to send 2 times the same attribute in the same reply.
I've tried that but without surprise this send only the first part of the attribute
cpe2-lab@test.fr Cleartext-Password := "xxx" WiMAX-Packet-Data-Flow-Id=1, WiMAX-Service-Data-Flow-Id=1, WiMAX-Service-Profile-Id=1, WiMAX-Direction=Bi-Directional, WiMAX-QoS-Id=01, WiMAX-Media-Flow-Type=Robust-Browser, WiMAX-Schedule-Type=BEST-EFFORT, WiMAX-Traffic-Priority=0, WiMAX-Maximum-Sustained-Traffic-Rate=512000, WiMAX-QoS-Id=02, WiMAX-Media-Flow-Type=Robust-Browser, WiMAX-Schedule-Type=BEST-EFFORT, WiMAX-Traffic-Priority=0, WiMAX-Maximum-Sustained-Traffic-Rate=512000
Maybe using perl module in the post-auth ?
Use += operator and add them twice. In whatever module you added them first time.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thomas Fagart wrote:
I've notice using Wireshark that Freeradius will "break" the TLV Attribut into two attributes parts.
This is likely because you are listing the attributes out of order. See dictionary.wimax, and ensure that the attributes are listed in numerical order.
I've read the documentation contains in dictionary.wimax at the beginning, I've the feeling that this might be related, but I don't understand it properly. (there's a part where it talks about size limitation ?)
Do you have a specific question?
So here are my questions
1. Is there a way to have it in one part ?
Yes. Read dictionary.wimax, and list the attributes in numerical order.
2. Is there's a way to specify the main attribute directly (instead of specifying each subattribute
Something like this
WiMAX-Packet-Flow-Descriptor=0x000104000102040001040303060301050304070301080302
That should work, too. Alan DeKok.
Thanx for your answer, Freeradius is now able to do local authentification for this Wimax Solution, which is great. Now I'm trying to do the following ASN <---- EAP/TTLS --> Radius A (Proxy) <---- Inner CHAP Request ----> Radius A The idea would be that Radius B only do simple authentication (ie send access accept without Wimax attribute), and Radius A would add Static Wimax Attribute in the Outer Tunnel reply, using post-proxy filter attrs. 1. I've tried to apply post-proxy filter in the inner-tunnel virtual server, but it doesn't seem to have an effect. 2. When I use it in the main virtual server (default for me), It works but not as I was expected to. Extract of attrs ################################### test.fr Service-Type := Framed-User, Framed-IP-Address := 172.16.3.33, EAP-Message =* ANY, Message-Authenticator =* ANY, # MS-CHAP2-Success =* ANY, # MS-MPPE-Recv-Key =* ANY, # MS-MPPE-Send-Key =* ANY, # MS-CHAP-MPPE-Keys =* ANY, # MS-MPPE-Encryption-Policy =* ANY, # MS-MPPE-Encryption-Types =* ANY, #3GPP2 Attribute 3GPP2-Service-Option-Profile := 0x000000010104B001, # WiMAX Attribute #WiMAX-Packet-Flow-Descriptor WiMAX-Packet-Data-Flow-Id := 1, WiMAX-Service-Data-Flow-Id := 1, WiMAX-Direction := 3, WiMAX-Activation-Trigger := 4, WiMAX-Transport-Type := 1, WiMAX-Uplink-QOS-Id := 1, WiMAX-Downlink-QOS-Id := 2, #WiMAX-QoS-Descriptor 1 # WiMAX-QoS-Descriptor:= 000103010C030204030205030006060001F400 WiMAX-QoS-Id := 1, WiMAX-Schedule-Type := 2, WiMAX-Traffic-Priority := 0, WiMAX-Maximum-Sustained-Traffic-Rate := 128000, WiMAX-Media-Flow-Type := 2, #WiMAX-QoS-Descriptor 2 # WiMAX-QoS-Descriptor:= 000103020C030204030205030006060001F400 WiMAX-QoS-Id := 2, WiMAX-Schedule-Type := 2, WiMAX-Traffic-Priority := 0, WiMAX-Maximum-Sustained-Traffic-Rate := 1024000, WiMAX-Media-Flow-Type := 2 ######################################## With that configured I've got the following reply Mon Apr 6 17:39:35 2009 Packet-Type = Access-Accept Service-Type := Framed-User Framed-IP-Address := 172.16.3.33 3GPP2-Service-Option-Profile := 0x000000010104b001 WiMAX-Packet-Data-Flow-Id := 1 WiMAX-Service-Data-Flow-Id := 1 WiMAX-Direction := Bi-Directional WiMAX-Activation-Trigger := 4 WiMAX-Transport-Type := IPv4-CS WiMAX-Uplink-QOS-Id := 1 WiMAX-Downlink-QOS-Id := 2 WiMAX-QoS-Id := 1 WiMAX-Schedule-Type := Best-Effort WiMAX-Traffic-Priority := 0 WiMAX-Maximum-Sustained-Traffic-Rate := 128000 WiMAX-Media-Flow-Type := Robust-Browser WiMAX-QoS-Id := 2 WiMAX-Schedule-Type := Best-Effort WiMAX-Traffic-Priority := 0 WiMAX-Maximum-Sustained-Traffic-Rate := 1024000 WiMAX-Media-Flow-Type := Robust-Browser MS-MPPE-Recv-Key = 0x71ed589b8e837324d47495472db7da4dd6b0de3ec00989e1302fe293c667619c MS-MPPE-Send-Key = 0x8d810a02c7ba85a7a6f43a8ade921b5828306c1f8a5ae3b07a4ca087edb8add6 EAP-MSK = 0x71ed589b8e837324d47495472db7da4dd6b0de3ec00989e1302fe293c667619c8d810a02c7ba85a7a6f43a8ade921b5828306c1f8a5ae3b07a4ca087edb8add6 EAP-EMSK = 0xa79a1c166e077a2e02f60d07980c6b46c334c78f24fb084cc31050d558f0d25f469961d048daf09dbdbbd0e6acbf1219926b1c39453f583c51e4b622e9a688c6 EAP-Message = 0x03720004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "00210400E0D7@test.fr" which is what I want, but in that case, the chap challenge won't be send to ASN (cause MS-CHAP2-Success is commented). If i'm enable MS-CHAP2-Success attribute, then the chap challenge is being sent, but the reply becomes Mon Apr 6 17:44:06 2009 Packet-Type = Access-Accept Service-Type := Framed-User Framed-IP-Address := 172.16.3.33 3GPP2-Service-Option-Profile := 0x000000010104b001 WiMAX-Packet-Data-Flow-Id := 1 WiMAX-Service-Data-Flow-Id := 1 WiMAX-Direction := Bi-Directional WiMAX-Activation-Trigger := 4 WiMAX-Transport-Type := IPv4-CS WiMAX-Uplink-QOS-Id := 1 WiMAX-Downlink-QOS-Id := 2 WiMAX-QoS-Id := 2 WiMAX-Schedule-Type := Best-Effort WiMAX-Traffic-Priority := 0 WiMAX-Maximum-Sustained-Traffic-Rate := 1024000 WiMAX-Media-Flow-Type := Robust-Browser MS-MPPE-Recv-Key = 0x8975a67313e522170555477b8af1736aa7d82bafcad34af2ea4a01b3284bf453 MS-MPPE-Send-Key = 0xcf575423d99ebcb96651472e306a1ef2d8740705dbe83343a97bdef699fc4f08 EAP-MSK = 0x8975a67313e522170555477b8af1736aa7d82bafcad34af2ea4a01b3284bf453cf575423d99ebcb96651472e306a1ef2d8740705dbe83343a97bdef699fc4f08 EAP-EMSK = 0xf1b5140862d8944cb3c4548b65faf80209f9d7a6432060534f63128d2554bb69abf81d0544068ce2c0c549ef620d5d217dd4857ba563709e014a4f14ad90dbbc EAP-Message = 0x03fa0004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "00210400E0D7@test.fr" -> In that case some of the Wimax attribute are missing (actually this is the attribute I've got twice with differents values). Do you have an idea how to explain that ? I agree that post-proxy filter might not be the good tool to do that (It should be use to filter, and I use it to add new attributes), maybe I should use policies instead ? Thanks Thomas
participants (3)
-
Alan DeKok -
Thomas Fagart -
tnt＠kalik.net