<div dir="ltr">Again, <br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 8:17 PM, Marki <span dir="ltr"><<a href="mailto:jm+freeradiususer@roth.lu" target="_blank">jm+freeradiususer@roth.lu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In fact the switches correctly react to an Access-Accept or Access-Reject,<br>
but don't set the VLAN correctly without EAP.<br></blockquote><div><br></div><div>I consider this a bug as there should be a separation of concerns here. It is totally unnecessary and a layering violation to couple to EAP.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In fact I have a call open with Cisco about this, and it would now be great<br>
if I had some strong arguments why using EAP here is just sick, or why some<br>
things only work with EAP while the rest also works out-of-the-box.<br></blockquote><div><br></div><div>I don't have a problem with EAP being used for MAC auth. A NAS could, for example, use a fixed, constant username and password to perform MAC address authentication, only passing the MAC address in the Calling-Station-Id, instructing that this value should be authenticated using the Service-Type of Call-Check.<br><br></div><div>This is useful as it means you can use a single directory account for MAC auth without having to mess around.<br><br></div><div>I do want to see Cisco implement and support a fixed, constant username and password authentication for MAB in a future IOS release. (As an option.)<br><br></div><div>If a Service-Type is missing, this is a bug where other authentication types are supported as it becomes awkward, hackish and potentially unreliable to discriminate between the type of service being used by a client. It becomes a broken NAS at this point.<br></div><div><br></div><div>Nick<br></div></div></div></div>