TEAP Chaining and Partial Success Policies

[Suriya Shankar]

Hi Alan,

I have a implementation of EAP-TEAP from EAP-FAST which is very similar to
what we have in the 3.2x where I am overriding the tls decision
"TEAP-Idenity-Ordinal" (gives me its machine/user)
+#define TEAP_MACHINE_CERT "1"
+#define TEAP_USER_CERT "2"
+
#ifdef ENABLE_OPENSSL_VERSION_CHECK
typedef struct libssl_defect {
uint64_t high;
@@ -1651,6 +1654,7 @@ static CONF_PARSER tls_server_config[] = {
#endif
{ "ca_path_reload_interval", FR_CONF_OFFSET(PW_TYPE_INTEGER,
fr_tls_server_conf_t, ca_path_reload_interval), "0" },
{ "allow_expired_crl", FR_CONF_OFFSET(PW_TYPE_BOOLEAN,
fr_tls_server_conf_t, allow_expired_crl), NULL },
+ { "allow_cert_failure", FR_CONF_OFFSET(PW_TYPE_BOOLEAN,
fr_tls_server_conf_t, allow_cert_failure), "no" },
{ "check_cert_cn", FR_CONF_OFFSET(PW_TYPE_STRING, fr_tls_server_conf_t,
check_cert_cn), NULL },
{ "cipher_list", FR_CONF_OFFSET(PW_TYPE_STRING, fr_tls_server_conf_t,
cipher_list), NULL },
{ "cipher_server_preference", FR_CONF_OFFSET(PW_TYPE_BOOLEAN,
fr_tls_server_conf_t, cipher_server_preference), NULL },
@@ -3145,6 +3149,23 @@ int cbtls_verify(int ok, X509_STORE_CTX *ctx)
X509_STORE_CTX_set_error( ctx, 0 );
}
+ if (!my_ok && (conf->allow_cert_failure)) {
+ VALUE_PAIR *teap_ordinal_vp = NULL;
+ DICT_ATTR const *teap_attr = dict_attrbyname("TEAP-Identity-Ordinal");
+ if (teap_attr) {
+ teap_ordinal_vp = fr_pair_find_by_da(request->packet->vps, teap_attr,
TAG_ANY);
+ // If TEAP User Certificate -> override the decision to success
+ if (strcmp(teap_ordinal_vp->vp_strvalue, TEAP_USER_CERT) == 0) {
+ DEBUG("TEAP context detected - Overriding User Cert Failure!");
+ my_ok = 1;
+ X509_STORE_CTX_set_error( ctx, 0 );
+ }
+ } else {
+ // TODO: Remove this later
+ DEBUG("Extracting teap_ordinal something went wrong!");
+ }
+ }

I know this is deviating from the RFC but I was able to override the TLS
failure if this helps

Thanks,
Suriya

On Tue, Dec 9, 2025 at 12:40 PM Jan Kříž <jan.kriz1867 at gmail.com> wrote:

> > The situation of *skipping* user authentication is very different from
> allowing *failed* user authentication.
> > TEAP explicitly allows the server to say certain kinds of authentication
> are allowed (but not required), or required.
>
> Oh I see, I misunderstood it completely. Thank you for pointing this out.
>
> > The server allows this today, with a manual / complex configuration.  It
> should be easier in a few weeks when I push some tweaks back.
> > What it doesn't support is "user tried to authenticate, and got a
> reject.  We still allow the overall TEAP authentication to succeed".  The
> TEAP specs don't envision this workflow.  I would be surprised if anything
> supported it.
>
> This is exactly what I tried to set up in FreeRADIUS some time ago,
> but I must have misconfigured something and if you say the
> configuration for this is complex, I most likely just did it wrong.
> Looking forward to those patches and thank you very much for
> clarifying this to me.
>
> On Tue, Dec 9, 2025 at 8:57 PM Alan DeKok <alan.dekok at inkbridge.io> wrote:
> >
> > On Dec 9, 2025, at 2:15 PM, Jan Kříž <jan.kriz1867 at gmail.com> wrote:
> > > To give a bit more context on why I went down this rabbit hole: I was
> > > researching options for handling "partial failures", specifically the
> > > "chicken and egg" scenario where a user certificate is missing on a
> > > freshly provisioned device.
> >
> >   The situation of *skipping* user authentication is very different from
> allowing *failed* user authentication.
> >
> >   TEAP explicitly allows the server to say certain kinds of
> authentication are allowed (but not required), or required.
> >
> > > That led me to a "Wires and Wi-Fi" blog
> > > post describing how TEAP is based on EAP-FASTv2 and how EAP chaining
> > > allows the server to make decisions based on combined states,
> > > including "User Failed and Machine Succeeded"
> > > (
> https://www.wiresandwi.fi/blog/windows-network-authentication-sequence).
> > >
> > > According to that explanation, Windows can perform machine-only
> > > authentication during startup, even when the user certificate does not
> > > exist yet, and the RADIUS server can return an Access-Accept with a
> > > restricted authorization profile. This gives the device enough limited
> > > network access to reach the PKI and enroll the missing user
> > > certificate.
> >
> >   Yes, that's explicitly allowed.  FreeRADIUS supports this with a bit
> of manual configuration.  I'm working on patches to make that easier.  They
> should be available in January.
> >
> > > I also found a Cisco ISE guide showing this workflow in practice, with
> > > explicit rules for "Machine authenticated, User not" that grant
> > > reduced access, distinct from the full "User and Machine" success
> > > state. (
> https://www.ise-support.com/2020/05/29/using-teap-for-eap-chaining/).
> > >
> > > Based on these examples, it appears that several commercial platforms
> > > intentionally treat the session as successful overall (sending
> > > Access-Accept), even when one inner method fails,
> >
> >   Again, you have to double / triple check the difference between "not
> doing user authentication", and "did user authentication, but it failed".
> >
> >   Many people confuse the two, which isn't good.
> >
> > > Given that this "partial success with restricted access" behavior
> > > seems to have become a de facto standard method for handling similar
> > > scenarios, I wanted to ask whether FreeRADIUS would consider
> > > supporting this mode?. Or is the project's stance that FreeRADIUS
> > > should follow the RFC strictly until the specification explicitly
> > > allows this behavior?
> >
> >   The server allows this today, with a manual / complex configuration.
> It should be easier in a few weeks when I push some tweaks back.
> >
> >   What it doesn't support is "user tried to authenticate, and got a
> reject.  We still allow the overall TEAP authentication to succeed".  The
> TEAP specs don't envision this workflow.  I would be surprised if anything
> supported it.
> >
> >   Alan DeKok.
> >
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>