[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: SQL MAC Authentication
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2013-12-18 17:58:23
Message-ID: 52B1E23F.2020706 () deployingradius ! com
[Download RAW message or body]

Christopher Kuhn wrote:
> It seems that the switch simply extracts the soruce MAC from any traffic, then \
> sends that as the username and password. This actually seems desirable, as it \
> doesn't require an actual 802.1X supplicant on the user end, and I would think this \
> would allow FreeRADIUS to process it like any standard EAP request.

  That's fine so far.

> > > WARNING: !! EAP session for state 0x8246357d82472c19 did not finish!
> > > WARNING: !! Please read
> > > http://wiki.freeradius.org/Certificate_Compatibility
> > 
> > That should be a hint. Did you read that page?
> 
> Yes; although that warning appears in the debug logs for our current auth method, \
> it has not interfered with authentication thus far.

  It indicates that there's a problem.  Would you ignore a large red
warning light on your car dashboard?

> > > [eap] Response appears to match, but EAP type is wrong.
> > 
> > The EAP supplicant is broken. FreeRADIUS sent it PEAP, and it
> > responded with EAP-MD5.
> > 
> > Take the switch, and throw it in the garbage. It's garbage.
> 
> The switch is *not* garbage. It's one of half a dozen SG500's in the network, \
> which, general reliability aside, have a 0% chance of being replaced.

  I really don't care.  It's garbage.  It's not following the EAP
specifications.  That is the root cause of the problem.

> Regardless, how did you know it was EAP-MD5?

  Because I can read the protocol traces from the hex EAP-Message.  I've
been doing this for ~15 years now.

> And is that the reason for its failure?

  No.  The failure is because FreeRADIUS tells the switch "Let's do
EAP-TTLS" (or whatever).  The switch responds with "OK, I'm doing
EAP-MD5".  That's broken.

  The switch SHOULD respond with an EAP NAK saying "No, I don't want
EAP-TTLS.  I want EAP-MD5".  But it doesn't.  So it's garbage.

> So are the other parts in this analogy radreply items, or something I don't quite \
> grasp?

  EAP depends on a large number of independent pieces.  If one works,
that doesn't mean EAP will succeed.  They ALL need to work.

> So the problem is the EAP type mismatch with the switch? 		 	   		  

  The problem is that the switch isn't following the EAP protocol.

  I don't care if you have a million other identical switches that work
perfectly.  This one is broken.

  Your choices are:

a) use a working switch

b) force FreeRADIUS to use EAP-MD5 for this switch.

  e.g.

authorize {
	...

	if (switch x) {
		update control {
			EAP-Type := MD5
		}
	}
	eap
	...
}

  (a) will always work.  (b) *might* work, but there's no guarantee.

  Once the switch refuses to follow proper procedure, *anything* can happen.

  You're better of fixing the switch than adding crap to your FreeRADIUS
configuration.  If all of the other switches behave this way, file a bug
report with Cisco.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]