(RADIATOR) bug in EAP.pm?

Jonathan Moore jonm at isc.upenn.edu
Thu Mar 25 10:38:20 CST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

We're in the process of trying to set up 802.1x wired authentication 
using Radiator as the back-end EAP server (specifically, we are doing 
EAP/TTLS/PAP). The following configuration works properly, but when a 
client is configured to try to connect using the *wrong* EAP method, 
Radiator is granting an Access-Accept anyway.

I've included the relevant configuration files and a level 4 trace 
(secrets removed).

Looking at the log, what happens is this:

Client send Access-Request containing an EAP Identity Response.
Radiator responds with Access-Challenge containing an EAP-Request 
initiating a TTLS handshake.
Client (for an unknown reason - it's configured to try EAP/MD5) 
responds with an Access-Request containing an identical EAP-Request 
initiating a TTLS handshake.
Radiator responds with an Access-Accept: not exactly the desired 
behavior!

The problem appears to be in the file EAP.pm, under the handling of EAP 
Request packets. In our case, Radiator will never play the supplicant 
role in an EAP conversation, so according to RFC 2284, it should 
"silently discard" any EAP-Request packets.

Is this a problem with:
   a. my understanding of RFC 2284 (EAP),
   b. my configuration file, or
   c. Radiator's EAP implementation?

Thanks,
Jon Moore
- --
Jon Moore
ISC Networking & Telecommunications
University of Pennsylvania

************************ radius.cfg file ************************
Foreground
PidFile         /usr/local/etc/radiator/pid
LogDir          /usr/local/etc/radiator/accounting
DbDir           /usr/local/etc/radiator
DictionaryFile  %D/dictionary,%D/dictionary.local

# temporary flatfile log, eventually we'll use syslog only
LogFile /usr/local/etc/radiator/log

# User a lower trace level in production systems:
Trace           4
#Trace		3

<Log SYSLOG>
	Facility daemon
#	Trace 4
	Trace 3
</Log>

<AuthLog SYSLOG>
         Facility daemon
         SuccessFormat '%u' from %N #%{NAS-Port} via %C %{Service-Type} 
- - OK
         FailureFormat '%u' from %N #%{NAS-Port} via %C %{Service-Type} 
- - FAILED

         LogSuccess
	LogFailure
	Identifier SyslogDaemon
</AuthLog>

# We never honor any user-supplied realm; instead we assign a specific 
realm
# to each RADIUS client host controlling who has access via that host.
RewriteUsername s/@.*$//

<Client somehost.example.com>
         Secret xxxxxx
         DefaultRealm extreme-users
</Client>
<Realm extreme-users>
         RewriteUsername s/@.*$//
	<AuthBy FILE>
		Filename %D/extreme-users
        	EAPType TTLS
		EAPTLS_CAFile %D/certs/CA.pem
		EAPTLS_CertificateFile %D/certs/cert-srv.pem
		EAPTLS_CertificateType PEM
		EAPTLS_PrivateKeyFile %D/certs/srv.key
		EAPTLS_MaxFragmentSize 1000
		SSLeayTrace 4
	</AuthBy>
	AcctLogFileName %L/detail
	AuthLog SyslogDaemon
</Realm>

# The following clause is for 802.1x users; the inner authentication
# tunnelled by TTLS will have no realm, thus we need the DEFAULT realm
# to catch them. The dot1x-users file only has a DEFAULT entry that
# checks for tunnelling within TTLS and then does a Kerberos 5
# authentication.
<Handler TunnelledByTTLS=1>
         RewriteUsername s/@.*$//
	<AuthBy FILE>
		Filename %D/test-users
	</AuthBy>
	<AuthLog SYSLOG>
		 Facility daemon
		 SuccessFormat '%u' from %N #%{NAS-Port} via 802.1x %C 
%{Service-Type} - OK
		 FailureFormat '%u' from %N #%{NAS-Port} via 802.1x %C 
%{Service-Type} - FAILED

		 LogSuccess
		 LogFailure
		 Identifier SyslogDaemon
	</AuthLog>
</Handler>

# Following clause implements an SNMP agent that supports MIB objects
# defined in RFC 2619 and 2621. Unfortunately, it only supports the
# weakly authenticated SNMP v1 protocol, sigh. Future work: implement
# SNMPv3 and reimplement this whole thing as a subagent using the
# AgentX protocol - shuque at isc.upenn.edu
<SNMPAgent>
	ROCommunity xxxxx
	Port 9991
	Managers localhost
</SNMPAgent>

# temporary, for testing with radpwtst
<Client localhost>
     Secret xxxxxx
     DupInterval 0
</Client>

*********************** extreme-users file ***************************
# this last line is present for 802.1x tunnelled authentication
anonymous	     Encrypted-Password = nevermatch

*********************** test-users file ******************************
netmon		Password = "somepass"

*********************** log file *************************************
Thu Mar 25 11:01:43 2004: DEBUG: Packet dump:
*** Received from 165.123.50.82 port 1411 ....
Code:       Access-Request
Identifier: 129
Authentic:  <0><0>2|<0><0><27><197><0><0>%<16><0><0>bL
Attributes:
	User-Name = "netmon"
	EAP-Message = <2><2><0><11><1>netmon
	NAS-IP-Address = 165.123.50.82
	Service-Type = Login-User
	Calling-Station-Id = "165.123.50.108"
	NAS-Port-Type = Virtual
	Message-Authenticator = 
<223>#<165><128>v\<189><154>y<24><184>s\<202><243>r

Thu Mar 25 11:01:43 2004: DEBUG: Rewrote user name 'netmon' to 'netmon'
Thu Mar 25 11:01:43 2004: DEBUG: Handling request with Handler 
'Realm=extreme-users'
Thu Mar 25 11:01:43 2004: DEBUG: Rewrote user name 
'netmon at extreme-users' to 'netmon'
Thu Mar 25 11:01:43 2004: DEBUG:  Deleting session for netmon, 
165.123.50.82,
Thu Mar 25 11:01:43 2004: DEBUG: Handling with Radius::AuthFILE:
Thu Mar 25 11:01:43 2004: DEBUG: Handling with EAP: code 2, 2, 11
Thu Mar 25 11:01:43 2004: DEBUG: Response type 1
Thu Mar 25 11:01:43 2004: DEBUG: Resuming session for 
Radius::Context=HASH(0x7956ec)

Thu Mar 25 11:01:43 2004: DEBUG: EAP result: 3, EAP TTLS Challenge
Thu Mar 25 11:01:43 2004: DEBUG: Access challenged for netmon: EAP TTLS 
Challenge
Thu Mar 25 11:01:43 2004: DEBUG: Packet dump:
*** Sending to 165.123.50.82 port 1411 ....
Code:       Access-Challenge
Identifier: 129
Authentic:  <0><0>2|<0><0><27><197><0><0>%<16><0><0>bL
Attributes:
	EAP-Message = <1><3><0><6><21>
	Message-Authenticator = 
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Thu Mar 25 11:01:43 2004: DEBUG: Packet dump:
*** Received from 165.123.50.82 port 1412 ....
Code:       Access-Request
Identifier: 132
Authentic:  <0><0>W<171><0><0><127>f<0><0><27><199><0><0>d<255>
Attributes:
	User-Name = "netmon"
	EAP-Message = <1><3><0><6><21>
	NAS-IP-Address = 165.123.50.82
	Service-Type = Login-User
	Calling-Station-Id = "165.123.50.108"
	NAS-Port-Type = Virtual
	Message-Authenticator = 
<181><197><165><164><132>+<27><170><169>g<20><200><31><19><134>>

Thu Mar 25 11:01:43 2004: DEBUG: Rewrote user name 'netmon' to 'netmon'
Thu Mar 25 11:01:43 2004: DEBUG: Handling request with Handler 
'Realm=extreme-users'
Thu Mar 25 11:01:43 2004: DEBUG: Rewrote user name 
'netmon at extreme-users' to 'netmon'
Thu Mar 25 11:01:43 2004: DEBUG:  Deleting session for netmon, 
165.123.50.82,
Thu Mar 25 11:01:43 2004: DEBUG: Handling with Radius::AuthFILE:
Thu Mar 25 11:01:43 2004: DEBUG: Handling with EAP: code 1, 3, 6
Thu Mar 25 11:01:43 2004: DEBUG: EAP Request 21
Thu Mar 25 11:01:43 2004: DEBUG: EAP result: 0,
Thu Mar 25 11:01:43 2004: DEBUG: Access accepted for netmon
Thu Mar 25 11:01:43 2004: DEBUG: Packet dump:
*** Sending to 165.123.50.82 port 1412 ....
Code:       Access-Accept
Identifier: 132
Authentic:  <0><0>W<171><0><0><127>f<0><0><27><199><0><0>d<255>
Attributes:



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFAYwsAx8TaElR3qMMRAnICAJ9xUR3QrpEp6rdGTa6eHci7pnmccACghPVn
VbDOWKHf49u2Q8h77ZZu0+c=
=MnCm
-----END PGP SIGNATURE-----

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list