cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
969
Views
8
Helpful
7
Replies

ISE Communication Model question

ahmad82pkn
Level 3
Level 3

Hi, I am unable to understand Point 3. Seems like its missing some clarity. Can someone expand on step 3 please?

Does NAD send Radius Challenge to Endpoint and then NAD forward it to PSN through RADIUS protocol? Is that what point 3 trying to say ? or PSN send Radius challenge to end point?Screenshot 2024-10-28 at 10.35.09 AM.png

1 Accepted Solution

Accepted Solutions

Yes, the NAD acts as a man-in-the-middle in between the endpoint and the RADIUS server (PSN). There is no direct communication between the endpoint and the RADIUS server nor between the RADIUS server and the endpoint, any messages between the RADIUS server and the endpoint or vice-versa will pass through the NAD.

Also please remember that the protocol used between the endpoint and the NAD is EAPoL, and between the NAD and the RADIUS server is RADIUS. So any messages between the endpoint and the NAD will be EAP messages and these messages will be converted into RADIUS packets between the NAD and the RADIUS server. This applies when the RADIUS packets come from the RADIUS server to the NAD, in that case the NAD will convert them in EAP before they are sent to the endpoint.

In simple words this what would happen during the EAP-TLS authentication process:
- The endpoint shows itself to the NAD by sending an EAPoL message by its supplicant which is the piece of software responsible to manage this EAP authentication process. This could be Cisco AnyConnect/Secure Client NAM, a third-party software, or event a native supplicant.
- The NAD asks the endpoint to provide its identity.
- The endpoint responds to the NAD.
- The NAD relay the endpoint identity to the RADIUS server via RADIUS.
- Based on the configured policies on the RADIUS server, the server will respond to the NAD with its decision.
- The NAD applies the enforcement action to the endpoint session based on the RADIUS server decision, this could be allow or deny or even more actions such as VLAN change, redirection, dACL etc.

As per my knowledge this is what would happen from EAP and RADIUS perspective:
- The endpoint sends the first EAP message to announce itself in an EAPoL-Start message.
- The NAD sends an EAP-Request/Identity message to the endpoint asking the endpoint to provide its identity.
- The endpoint responds to the NAD with an EAP-Response/Identity message with its identity.
- The NAD converts this message to the RADIUS server in a RADIUS Access-Request packet.
- The RADIUS server responds to the NAD with a RADIUS Access-Challenge packet. This would be step 3 you have on the guide and this starts the secure tunnel negotiation between the RADIUS server and the endpoint, still via the NAD.
- The NAD converts this packet into an EAP-Request/TLS start message and sends to the endpoint with the TLS proposal.
- The endpoint responds to the NAD with an EAP Response/TLS client hello message.
- The NAD converts this message in a RADIUS Access-Request packet and sends it to the RADIUS server.
- The RADIUS server responds to the NAD with another RADIUS Access-Challenge packet with its server hello and other additional attributes such as its key exchange, its certificate and also a request of the endpoint certificate.
- The NAD converts this packet into an EAP-
Response/TLS message and sends to the endpoint.
- The endpoint responds to the NAD with an EAP Response/TLS with its certificate, ciphers, and its key exchange.
- The NAD converts this message into another RADIUS Access-Request packet and sends it to the RADIUS server.
The RADIUS server responds to the NAD with another RADIUS Access-Challenge packet to finish the TLS negotiation.
- The NAD converts this packet into another EAP-Request/TLS with the secure tunnel attributes that have been agreed on between the RADIUS server and the endpoint and will then sends this message to the endpoint.
- The endpoint responds to the NAD with an EAP-Response message.
- The NAD converts this message in a RADIUS Access-Request packet and sends it to the RADIUS server.
The RADIUS server responds to the NAD with a RADIUS Access-Accept packet.
- The NAD converts this packet into an EAP-Success message. From here on the endpoint session would be authorized.

View solution in original post

7 Replies 7

This is really badly worded in that slide. I assume it is about 802.1X here. This is happening at this stage:

  1. (Optional) First, The client sends an EAPOL-START message to the NAD.
  2. The NAD sends an EAP Identity request to the client. This could be the answer to the EAPOL-START or it could be the start of the communication.
  3. The client answers with it's identity in a EAP-Response/Identity message. It could be a bogus identity like anonymous here as the client typically doesn't have to reveal it's real identity yet.
  4. This EAP-Response is encapsulated in a RADIUS request and sent to the AAA-server.
  5. More packets will get exchanged to finish the authentication.

These two blog posts might help you to understand the details:

https://cyber-fi.net/index.php/2023/05/30/ieee-802-1x-and-eap-part-1-the-basics/

https://cyber-fi.net/index.php/2023/05/31/ieee-802-1x-and-eap-part-2-packet-by-packet/

Marvin Rhoads
Hall of Fame
Hall of Fame

Very nice @Karsten Iwen - now we know you have a blog too!

The point in your blog post is key - the endpoint is talking to the NAD (switch or WLC) via EAPoL at first and does not even have an IP address yet. So the NAD does the RADIUS work and encapsulates/translates the EAPoL necessary details into RADIUS (which ISE speaks).

Cristian Matei
VIP Alumni
VIP Alumni

Hi, 

   Step 3 exists / is valid, only when we speak about EAP being used / enforced (when using MAB, step 3 is changed to "NAD" takes connected host MAC address and sends it via RADIUS to PSN). What step 3 with EAP means, to be 100% correct, is there the host will initiate EAP, either the NAD will initiate EAP, once NAD gets first EAP reply from host, to relays it to NAD via RADIUS.

Best,

Cristian.

Yes, the NAD acts as a man-in-the-middle in between the endpoint and the RADIUS server (PSN). There is no direct communication between the endpoint and the RADIUS server nor between the RADIUS server and the endpoint, any messages between the RADIUS server and the endpoint or vice-versa will pass through the NAD.

Also please remember that the protocol used between the endpoint and the NAD is EAPoL, and between the NAD and the RADIUS server is RADIUS. So any messages between the endpoint and the NAD will be EAP messages and these messages will be converted into RADIUS packets between the NAD and the RADIUS server. This applies when the RADIUS packets come from the RADIUS server to the NAD, in that case the NAD will convert them in EAP before they are sent to the endpoint.

In simple words this what would happen during the EAP-TLS authentication process:
- The endpoint shows itself to the NAD by sending an EAPoL message by its supplicant which is the piece of software responsible to manage this EAP authentication process. This could be Cisco AnyConnect/Secure Client NAM, a third-party software, or event a native supplicant.
- The NAD asks the endpoint to provide its identity.
- The endpoint responds to the NAD.
- The NAD relay the endpoint identity to the RADIUS server via RADIUS.
- Based on the configured policies on the RADIUS server, the server will respond to the NAD with its decision.
- The NAD applies the enforcement action to the endpoint session based on the RADIUS server decision, this could be allow or deny or even more actions such as VLAN change, redirection, dACL etc.

As per my knowledge this is what would happen from EAP and RADIUS perspective:
- The endpoint sends the first EAP message to announce itself in an EAPoL-Start message.
- The NAD sends an EAP-Request/Identity message to the endpoint asking the endpoint to provide its identity.
- The endpoint responds to the NAD with an EAP-Response/Identity message with its identity.
- The NAD converts this message to the RADIUS server in a RADIUS Access-Request packet.
- The RADIUS server responds to the NAD with a RADIUS Access-Challenge packet. This would be step 3 you have on the guide and this starts the secure tunnel negotiation between the RADIUS server and the endpoint, still via the NAD.
- The NAD converts this packet into an EAP-Request/TLS start message and sends to the endpoint with the TLS proposal.
- The endpoint responds to the NAD with an EAP Response/TLS client hello message.
- The NAD converts this message in a RADIUS Access-Request packet and sends it to the RADIUS server.
- The RADIUS server responds to the NAD with another RADIUS Access-Challenge packet with its server hello and other additional attributes such as its key exchange, its certificate and also a request of the endpoint certificate.
- The NAD converts this packet into an EAP-
Response/TLS message and sends to the endpoint.
- The endpoint responds to the NAD with an EAP Response/TLS with its certificate, ciphers, and its key exchange.
- The NAD converts this message into another RADIUS Access-Request packet and sends it to the RADIUS server.
The RADIUS server responds to the NAD with another RADIUS Access-Challenge packet to finish the TLS negotiation.
- The NAD converts this packet into another EAP-Request/TLS with the secure tunnel attributes that have been agreed on between the RADIUS server and the endpoint and will then sends this message to the endpoint.
- The endpoint responds to the NAD with an EAP-Response message.
- The NAD converts this message in a RADIUS Access-Request packet and sends it to the RADIUS server.
The RADIUS server responds to the NAD with a RADIUS Access-Accept packet.
- The NAD converts this packet into an EAP-Success message. From here on the endpoint session would be authorized.

Thank you for your detailed response. Will be helpful in tshoot as well.

I wouldn't use the term "convert" in this context to describe it accurately. The EAP part from the endpoint is taken as it is and encapsulated inside RADIUS, where other attributes are added. In return, the EAP attribute is also not converted but just sent along to the endpoint.

That's correct, it was just to simplify the context of the steps but thanks for pointing that out.