MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5

[Alan DeKok]

On Mar 3, 2015, at 10:33 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> Well, it expects a response or a plain NAK there because that's what MS-PEAP says are the only valid replies, once you pick apart the state machine.
> 
> It's probably a good idea to be looser and accept the expanded NAK too, on the FR side; no real harm to it.

  It’s not an expanded NAK.  It’s a gigantic piece of garbage.  The supplicant should be thrown in the garbage.  It goes like this:

  FreeRADIUS does PEAP.  Once the inner tunnel is set up, FR sends an EAP-MSCHAPv2 challenge packet.

  The supplicant responds with an extended type:

0x021d 0046 fe extended type
000000  IETF Private enterprise code
0000001a EAP-MSCHAPv2
021d 003a 31 ???? Another EAP packet with EAP-Type 49, EAP-IKEv2 ???

  And then this:

6e882ba02b15bc9aec09decfe03db1fb0000000000000000ad6990749d5255b204c8a2d90fe0e1496dc5ee88dc54bfc30074657374 

  The supplicant is a piece of garbage.  There is NO REASON to send an extended type packet.  On top of that, the contents of the extended type are the actual EAP type data.  NOT another EAP packet with EAP header, length, etc.

  All of this nonsense could have been avoided if the OP posted the debug log as suggested in the FAQ, README, “man” pages, web pages, and daily on this list.  But no…making it hard for people to help you is a *great* idea.

  Alan DeKok.