MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5

[Krause, Kilian]

Hi Alan,

> > Do you reckon that using tunneled reply (which we obviously need to
> support CUI on eduroam) shouldn't break MACSEC? If so, why are is
> activating it in the FR default config breaking MACSEC in my lab and what
> might be a possible fix for this?
> 
> this sort of thing is usually because you are leaking things from the
> inner to the outer which clash
> with the NAS's idea of whats going on - eg you are leaking the User-Name
> from the inner to the outer...thus
> negating the point of an anonymous outerID - which is what CUI is actually
> for ;-)

Thanks for the hint.

I've already implemented a reset of the outer User-Name reply in post-auth to the one received in the outer tunnel request. Somewhat that feels a bit counter intuitive but it was the logical consequence of the howto telling me I'd need use_tunneled_reply for CUI to work at all. I'd love to not use use_tunneled_reply, but so far my tests failed to update the outer reply with the value from the inner tunnel directly. So, how would I be leaking just this info about the "real" user-Name from the inner tunnel alone without use_tunneled_reply?

 
> to confirm/verify, either dont play with/expose the inner User-Name or set
> the client to have the
> same outerid as its innerid  (eg classic Windows behaviour)

We never exposed the inner User-Name for obvious reasons.

So do you reckon it's either CUI or MACSEC working? Can use_tunneled_reply be updated dynamically based upon NAS-Port-Type?

I'm also still trying to understand what breaks PEAP-MSCHAPv2 when pulling authentication from AD rather than using local accounts on the FR (the latter works just fine with MACSEC).

Best,
Kilian