RFC compliance for Access Challenge
Hi, As per RFC, it looks like the Access Challenge must not contain any attributes other than Reply-Message, State, Vendor-Specific, Session-Timeout and Idle-Timeout. But if i put the configuration options as below for the EAP user 'USER5', then the access challenge from Free Radius server contains those attributes. USER5 Cleartext-Password := "xyz" Service-Type = Framed-User, Framed-IP-Address = 255.255.255.255, Framed-MTU = 576, Tunnel-Medium-Type = "6", Tunnel-Type = "VLAN", Tunnel-Private-Group-Id = 400, Please find the debug logs below: Version: radiusd: FreeRADIUS Version 2.1.10, for host i686-pc-linux-gnu, built on Jun 8 2011 at 15:45:1 Debug logs (Have changed the IP address) -------------------------------------------------------------- Ready to process requests. rad_recv: Access-Request packet from host AA.BB.CC.DD port 1812, id=38, length=94 NAS-IP-Address = DD.EE.AA.DD NAS-Port-Type = Ethernet NAS-Port = 43 Calling-Station-Id = "00-00-01-00-04-00" User-Name = "USER5" EAP-Message = 0x0239000a015553455235 Message-Authenticator = 0x8db99a77b408552561675e84e7840868 # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "USER5", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 57 length 10 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated [files] users: Matched entry USER5 at line 215 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /usr/local/etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] EAP Identity [eap] processing type md5 rlm_eap_md5: Issuing Challenge ++[eap] returns handled Sending Access-Challenge of id 38 to DD.EE.AA.DD port 65163 Service-Type = Framed-User Framed-IP-Address = 255.255.255.255 Framed-MTU = 576 Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Tunnel-Private-Group-Id:0 = "400" EAP-Message = 0x013a00160410f646c8b9a0a056801f6d89a3d919ccc5 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xda41235ada7b273294cf6090be1d930c Finished request 4. Going to the next request Waking up in 4.9 seconds. -------------------------------------------------------------- Would like to know why Free Radius is putting the user configuration data in Access Challenge ? Appreciate the early response on the same, Thanks, -Sanal
Hi,
Would like to know why Free Radius is putting the user configuration data in Access Challenge ?
as per attrs.access_challenge # This configuration file is used to remove almost all of the # attributes From an Access-Challenge message. The RFC's say # that an Access-Challenge packet can contain only a few # attributes. We enforce that here. # DEFAULT EAP-Message =* ANY, State =* ANY, Message-Authenticator =* ANY, Reply-Message =* ANY, Proxy-State =* ANY, Session-Timeout =* ANY, Idle-Timeout =* ANY this would suggest strongly that you arent actually USING this filter to follow the RFCs that you are so strongly advocating in your post - this filter file is define in modules/attrs attr_filter attr_filter.access_challenge { key = %{User-Name} attrsfile = ${confdir}/attrs.access_challenge } now....read the sites-enabled/default as provided with the server, scroll down to the 'eap' authentication and then you'll see the next 12 lines have the bit that will enable this filter. its commented out by default because its an RFC that not many people care about (having seen junk from IAS/NPS and ACS, FreeRADIUS is already *quite* RFC compliant without tis extra bit of OCD ;-) alan
Cool.... Thanks a lot for the quick response and info... :-) Thanks, -Sanal On Mon, Dec 12, 2011 at 6:36 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Would like to know why Free Radius is putting the user configuration data in Access Challenge ?
as per attrs.access_challenge
# This configuration file is used to remove almost all of the # attributes From an Access-Challenge message. The RFC's say # that an Access-Challenge packet can contain only a few # attributes. We enforce that here. # DEFAULT EAP-Message =* ANY, State =* ANY, Message-Authenticator =* ANY, Reply-Message =* ANY, Proxy-State =* ANY, Session-Timeout =* ANY, Idle-Timeout =* ANY
this would suggest strongly that you arent actually USING this filter to follow the RFCs that you are so strongly advocating in your post - this filter file is define in modules/attrs
attr_filter attr_filter.access_challenge { key = %{User-Name} attrsfile = ${confdir}/attrs.access_challenge }
now....read the sites-enabled/default as provided with the server, scroll down to the 'eap' authentication and then you'll see the next 12 lines have the bit that will enable this filter. its commented out by default because its an RFC that not many people care about (having seen junk from IAS/NPS and ACS, FreeRADIUS is already *quite* RFC compliant without tis extra bit of OCD ;-)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
sanal kumar kariazhath wrote:
As per RFC, it looks like the Access Challenge must not contain any attributes other than Reply-Message, State, Vendor-Specific, Session-Timeout and Idle-Timeout.
Alan Buxey already had a good response. Mine is: Who cares? What problem does it create? A fanatical dedication to RFC compliance is wrong. For the simple reason that the RFCs are often wrong. I know because I wrote RFC 5080, which talks about what's wrong with other RFCs. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
sanal kumar kariazhath