Incorrect trust anchor reported as radius authentication rejected

[Sam Hartman]

If you have a trust anchor specified that does not match the target realm, then you get a radius authentication rejected error.
You can see the real problem if you set the GSSEAP_TRACE environment variable.
Two issues here. First, this should be reported with a better error return.
Secondly, though, the fact that we're getting to a RADIUs reject suggests the client state machine is broken.
What if the other side were to return a success or something like that. I suspect the lack of an EAP key would save us, but it seems like the client should consider trust anchor validation more fatal and definitely should report the error more correctly.

[Linus Nordberg (f-linus)]

Sounds like a libradsec issue. Is that correct?

Out of curiosity, can you elaborate on the comment about lacking an EAP key in the success (RADIUS authn) case?

[Sam Hartman (hartmans)]

>>>>> "Linus" == Linus Nordberg <email address hidden> writes:

    Linus> Sounds like a libradsec issue. Is that correct? Out of
    Linus> curiosity, can you elaborate on the comment about lacking an
    Linus> EAP key in the success (RADIUS authn) case?

no.
This is the trust anchor between the EAP supplicant and EAP server.

so, if a RADIUS server returns a premature success indication before eap
actually succeeds, the client will not have an EAP key.
OUr state machine requires that for the next step.
So, we'd fail at that stage rather than having a mutual authentication
security problem.

--Sam