TEAP Chaining and Partial Success Policies

[Alan DeKok]

On Dec 9, 2025, at 11:06 AM, Jan Kříž <jan.kriz1867 at gmail.com> wrote:
> I'm following up on a thread from with the subject of "EAP-TEAP not
> doing 2nd inner Method" from December 2024
> (https://lists.freeradius.org/pipermail/freeradius-users/2024-December/105155.html)
> about TEAP and setting network policies based on partial success
> (e.g., Machine cert succeeds, but User cert fails).

  I really don't see how that is supported by anything.  I've spent about 3 years going over the TEAP specifications, and the TEAP implementations.  I don't see anything in them which allows that work flow.

  The inner authentications are bound to the outer TLS session via various crypto magic.  The result is that the outer authentication succeeds only when the inner authentication succeeds.

  So I don't see any way in the specification which could allow machine EAP-TLS to succeed, fail at user EAP-TLS, but still allow the user online.

  I could very well be missing something.  But if I am, then this behavior is not explicitly allowed by the specification.  So it's an accidental outcome.  The specification needs to be updated to mention this, and then either explicitly allow it, or forbid it.

> I agree that the client side is a huge hurdle here, but I’m confused
> because some commercial platforms like Cisco ISE and Aruba ClearPass
> explicitly advertise and allow admins to configure different
> VLANs/ACLs precisely for that partial success scenario.
> 
> Since the commercial vendors seem to have found a way to achieve this,
> are they relying on some vendor-specific extensions or a different,
> non-TEAP chaining method entirely? Is it possible to configure this in
> FreeRADIUS at all?

  You'll have to try it and see.  I don't have time right now to test it, unfortunately.

> Any insight into how FreeRADIUS could be configured to accurately
> process the final result and differentiate between Machine-only,
> User-only success and Full success would be hugely helpful.

  You will have to update the "eap_teap.c" code to allow TEAP to continue when one of the inner methods fails.  Right now, an inner reject results in the entire TEAP session failing.

  You can't edit the configuration to allow this.  When the TEAP code was written, I was assuming that failure means failure.  If the Windows TEAP implementation is OK with the above work flow, then that's a surprising bit of information.

  Alan DeKok.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20251209/12189cac/attachment.sig>