SQL MAC Authentication

[Alan DeKok]

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.