(RADIATOR) bug in EAP.pm?
Mike McCauley
mikem at open.com.au
Thu Mar 25 21:35:14 CST 2004
Hello Jonathan,
thanks for reporting this issue and your helpful notes and log files.
The answer is 'c'.
We have now posted a patch so that all EAP requests (other than notifications)
will be logged and ignored.
Pls let us know if it works OK for you.
We apologise for any inconvenience.
Cheers.
On Fri, 26 Mar 2004 02:38 am, Jonathan Moore wrote:
> 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:
--
Mike McCauley mikem at open.com.au
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au
Phone +61 7 5598-7474 Fax +61 7 5598-7070
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS etc.
--
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