How to cleanly shut down a PEAP TLS tunnel

[Alan DeKok]

On Sep 11, 2023, at 7:36 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> 
> I've got a client that tries to shut down the TLS tunnel used for PEAP
> after running through the full authentication process and getting the
> Access-Accept/Success at the end.

  That's good.

>  However the Access-Accept/Success
> comes in without a State attribute, and if the TLS Close-Alert
> (appropriately wrapped in several layers of outer protocols) is sent
> that way then FreeRADIUS reports:

  I don't know what that means.  The Access-Accept doesn't need to contain a State.  And it doesn't contain a TLS Close-Alert.  The Access-Accept just contains EAP Success.

  If the client sends a TLS close alert, it must send it in an Access-Request, with a State attribute from the previous packet.

  If the server sends a TLS close alert, it must send it in an Access-Challenge, with a State attribute.

> (18) eap: ERROR: EAP requires the State attribute to work, but no
> State exists in the Access-Request packet.
> (18) eap: ERROR: The RADIUS client is broken.  No amount of changing
> FreeRADIUS will fix the RADIUS client.
> (18) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request

  You've somehow broken the EAP state machine.  Why?

  And just post the full debug output... I have no idea why you're asking us to debug a complex packet flow and then *not* posting the full packet flow.

  English descriptions of what's going on are vague, or even wrong.  The packet flow is easy to post (cut & paste).  It contains a huge amount of information about *exactly* what's going on.

> If OTOH I use the State value from the last message preceding the
> Access-Accept/Success I get:
> 
> (37) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x57f74ed950ff57da
> (37) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request

  So... the client replies to the Access-Accept with another Access-Request?  That makes no sense.

> What's the correct way to perform a clean shutdown of the TLS tunnel
> after completing the PEAP authentication process?  Or do you just
> leave it hanging? Although no two diagrams seem to be able to agree on
> what happens at this point, one example is this:

  I have no idea what you mean about "clean shutdown of the TLS tunnel".  When the supplicant sees an Access-Accept with EAP Success, it maybe keeps a TLS session ticket, and then discards everything else about the TLS session.

 Why would the supplicant (or RADIUS client) send an Access-Request back to the RADIUS server which says "Thanks for letting me online, I've closed my TLS connection!"

 It's not needed.  Don't do it.

> https://mrncciew.files.wordpress.com/2014/08/eap-peap-20.png
> 
> which tears down the tunnel at step 15 and then the client gets the
> Access-Accept/Success at step 16/17, while with FreeRADIUS I'm getting
> the Access-Accept/Success before the TLS tunnel is torn down

  That's fine.

> and then
> one of the two errors above with an attempt to tear down the tunnel.

  No, you get those errors when the server thinks that the TLS session is finished, and you try to hack up the RADIUS state machine in a way which isn't allowed.

  If the client gets an Access-Accept, that's it.  The TLS session is over.  There is no need to send the RADIUS server anything.

  Alan DeKok.