EAP-TEAP not doing 2nd inner Method

[Alan DeKok]

On Dec 9, 2024, at 7:40 AM, Martin B. <martinbiniek at googlemail.com> wrote:
> > It's really an illusion of extra security. 
> 
>  Yes, and I agree with you on that. 
> For me, it was never about the 'extra security' that this protocol was supposed to provide (by checking two certificates from the same device), but rather about detecting missing certificates.
> Depending on whether a) certificate 1 and 2 are present, b) only certificate 1 is present, or c) only certificate 2 is present, or d) no certificate is present, I want to be able to perform different actions. 
> For example: 
> a) grant access to the internal network
> b) move device into a special network segment where the missing certificates can be automatically deployed, then do re-auth
> c) grant access to the internal network
> d) reject access to the internal network
> 
> Or in other words, when a user is logged into a new machine where he does not yet have a certificate installed (but is necessary, for example to know what ressources this user is allowed to access), I need to trust the machine first before I move it into the special network segment (and deploy the certificate of the user).

  That's an admirable work flow, but it's probably not going to work.

> Even though it might be possible to achieve this through other means, I think it would be most elegant if everything could be done in one go, without having to manually create a custom configuration on the server. 
> However, when you look at EAP-TEAP and see how strictly the server must adhere to the client's requirements for the protocol to work, a custom configuration might be the easiest way (at least for now, until the protocol is revised and all implementations comply with the updates).

  Exactly.  None of the implementations (even Windows) support this workflow.

  I really don't understand what's intended with TEAP.  Many people are pushing it, for reasons which they can't explain.  But it's new, so it's great, right?

  Oh well.

> It looks like the Identity-Types do not get deleted properly which causes the server to request a 3rd EAP-Identity.

  Please post the FULL debug output for one session.  This output starts in the middle of a session, which makes it difficult to see what's going on.  If it's big, just send it to me off-list, and I'll take a look.

  In order for the new configuration to work, you can't set the FreeRADIUS-EAP-TEAP-Identity-Type via "unlang".  That will likely cause issues.

  From what I can tell, it looks like it's starting another TEAP session inside of the virtual server.  That doesn't seem right.  The inner session should be EAP-TLS, EAP-MD5, etc.

  Why is the inner tunnel method doing TEAP?  You should not be doing TEAP inside of TEAP.  That won't work.

  Even the previous "unlang" configuration I posted here set the inner EAP-Type to EAP-TLS.  So there's no reason to do TEAP inside of TEAP.  I'll push a fix which checks for this and complains.

  Alan DeKok.