Multiple instances of attribute in tunnelled reply
Hi, We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept. It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute. For example: users / sql DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~ "^.1........$" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 603, Reply-Message = "User %{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access on NAS:%{%{NAS-Identifier}:-Uknown NAS} SSID:%{%{Called-Station-SSID}:-none}.", HP-IP-FILTER-RAW = 'deny in 41 from any to any', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5', Fall-Through = no Ends up being sent as the response: # server default-inner PEAP: Got tunneled reply RADIUS code 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ac221" PEAP: Processing from tunneled session code 0x845cb10 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ac221" PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS Saving tunneled attributes for later So when it's actually used in the Access-Accept packet it appears as: Sending Access-Accept of id 173 to 139.184.8.16 port 1024 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" HP-Ip-Filter-Raw = "deny in 41 from any to any" User-Name = "ac221@sussex.ac.uk" MS-MPPE-Recv-Key = 0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03 MS-MPPE-Send-Key = 0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696 EAP-Message = 0x034a0004 Message-Authenticator = 0x00000000000000000000000000000000 Finished request 9. What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out. Relevant EAP bits: eap { ... ttls { ... copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "default-inner" } } Thanks, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Erg, Still no closer to fixing this / finding a work around. Is anyone else using a similar configuration and finding this issue? Arran Arran Cudbard-Bell wrote:
Hi,
We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept. It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute.
For example:
users / sql
DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~ "^.1........$" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 603, Reply-Message = "User %{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access on NAS:%{%{NAS-Identifier}:-Uknown NAS} SSID:%{%{Called-Station-SSID}:-none}.", HP-IP-FILTER-RAW = 'deny in 41 from any to any', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5', Fall-Through = no
Ends up being sent as the response:
# server default-inner PEAP: Got tunneled reply RADIUS code 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ac221" PEAP: Processing from tunneled session code 0x845cb10 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ac221" PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS Saving tunneled attributes for later
So when it's actually used in the Access-Accept packet it appears as:
Sending Access-Accept of id 173 to 139.184.8.16 port 1024 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" HP-Ip-Filter-Raw = "deny in 41 from any to any" User-Name = "ac221@sussex.ac.uk" MS-MPPE-Recv-Key = 0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03 MS-MPPE-Send-Key = 0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696 EAP-Message = 0x034a0004 Message-Authenticator = 0x00000000000000000000000000000000 Finished request 9.
What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out.
Relevant EAP bits:
eap { ... ttls { ... copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "default-inner" } }
Thanks, Arran
Arran Cudbard-Bell wrote:
Hi,
We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept.
... update outer.reply { User-Name := "foo" } ...
It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute.
Ah.... the code in "unlang" was fixed to correct this problem. The basic API used in the basic RADIUS library wasn't fixed. Ok... I'll take a look at it when I get back from my current trip.
What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out.
Yes. "copy everything", versus "merge via operators". Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Hi,
We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept.
... update outer.reply { User-Name := "foo" } ...
Hmm, it's complicated... there are authorisation issues too.
It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute.
Ah.... the code in "unlang" was fixed to correct this problem. The basic API used in the basic RADIUS library wasn't fixed.
Ok... I'll take a look at it when I get back from my current trip.
Ok that helps, didn't realise it was fixed in unlang; least I can get some dynamic ACL testing done.
What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out.
Yes. "copy everything", versus "merge via operators".
Yep.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
participants (2)
-
Alan DeKok -
Arran Cudbard-Bell