Re: Multiple instances of attribute in tunnelled reply
Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! sunhualing On Wed, Apr 14, 2010 at 10:59 AM, Alan DeKok al...@deployingradius.comwrote: sunhualing wrote: Hello everyone: I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get a problem that some attribute missing in the Access-Accept message, while it appears in the first Access-Challenge message. I still find that those attributes appear tunneled reply , i use the debug mode. Search the mail list , i find that similiar problem appears two years ago, here is the mail. Any suggestion is welcome, thanks a log Hmm... the fix is likely to edit the source code of the PEAP module. I'll take a look at it for 2.1.9. 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
Re: Multiple instances of attribute in tunnelled reply
sunhualing wrote: Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! They both have the same code, and they both should be fixed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Thanks very much, I wish that the version 2.1.9 will be released soon. Sunhualing On Wed, Apr 14, 2010 at 3:02 PM, Alan DeKok al...@deployingradius.comwrote: sunhualing wrote: Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! They both have the same code, and they both should be fixed. 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
Multiple instances of attribute in tunnelled reply
Hello everyone:
I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get
a problem that some attribute missing in the
Access-Accept message, while it appears in the first Access-Challenge
message. I still find that those attributes appear
tunneled reply , i use the debug mode.
Search the mail list , i find that similiar problem appears two years
ago, here is the mail.
Any suggestion is welcome, thanks a log
sunhualing
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 = 0x
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 = 0x
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 = ac...@sussex.ac.uk
MS-MPPE-Recv-Key =
0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03
MS-MPPE-Send-Key =
0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696
EAP-Message = 0x034a0004
Message-Authenticator = 0x
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
sunhualing wrote: Hello everyone: I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get a problem that some attribute missing in the Access-Accept message, while it appears in the first Access-Challenge message. I still find that those attributes appear tunneled reply , i use the debug mode. Search the mail list , i find that similiar problem appears two years ago, here is the mail. Any suggestion is welcome, thanks a log Hmm... the fix is likely to edit the source code of the PEAP module. I'll take a look at it for 2.1.9. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hi, I think that I have a similar problem when freeradius has to send Access-Accept with multiple Cisco-AVPair=ssid=... entries. Do you think it will be fixed in the near future ? Thanks. Konstantin _ Konstantin KABASSANOV LIP6/CNRS 104, avenue du Président Kennedy, 75016 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com Certificate: http://igc.services.cnrs.fr/CNRS-Standard/recherche.html _ smime.p7s Description: S/MIME cryptographic signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
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 ([EMAIL PROTECTED])
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
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 = 0x
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 = 0x
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 = [EMAIL PROTECTED]
MS-MPPE-Recv-Key =
0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03
MS-MPPE-Send-Key =
0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696
EAP-Message = 0x034a0004
Message-Authenticator = 0x
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 = 0x
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 = 0x
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 = [EMAIL PROTECTED]
MS-MPPE-Recv-Key =
0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03
MS-MPPE-Send-Key =
0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696
EAP-Message = 0x034a0004
Message-Authenticator = 0x
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 ([EMAIL PROTECTED])
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
