Solved: Re: ISE 2.3 EAP message format

Laurent Aubert · ‎02-09-2018

Hi,

I have an environment where my authenticator is an IOS router and my supplicant an IoT endpoint. I'm trying to do EAP-TLS to authenticate the endpoint.

The authenticator will send the first EAP-Request to get the supplicant Identity with an EAP Id of 0x01:

128450: Feb 7 14:17:05.329: EAPOL pak dump Tx

128451: Feb 7 14:17:05.329: EAPOL Version: 0x3 type: 0x0 length: 0x0005

128452: Feb 7 14:17:05.329: EAP code: 0x1 id: 0x1 length: 0x0005 type: 0x1

As expected the endpoint reply back with an EAP Response using the same Id value as stated in the RFC. This response is encapsulated into a Radius access-request packet and sent to the ISE server:

128480: Feb 7 14:17:05.355: RADIUS(00000477): Send Access-Request to 10.10.203.253:1812 onvrf(0) id 1645/121, len 238

128481: Feb 7 14:17:05.355: RADIUS: authenticator 45 B4 04 B9 E6 BB D1 6D - DA 00 98 3A 8D 20 A8 B1

128482: Feb 7 14:17:05.355: RADIUS: User-Name [1] 20 "host/LabGlobalCert"

128483: Feb 7 14:17:05.355: RADIUS: Service-Type [6] 6 Framed [2]

128484: Feb 7 14:17:05.355: RADIUS: Vendor, Cisco [26] 27

128485: Feb 7 14:17:05.355: RADIUS: Cisco AVpair [1] 21 "service-type=Framed"

128486: Feb 7 14:17:05.355: RADIUS: Framed-MTU [12] 6 1500

128487: Feb 7 14:17:05.355: RADIUS: Called-Station-Id [30] 19 "01-05-00-4C-00-40"

128488: Feb 7 14:17:05.355: RADIUS: Calling-Station-Id [31] 19 "01-07-00-27-00-2C"

128489: Feb 7 14:17:05.357: RADIUS: EAP-Message [79] 25

128490: Feb 7 14:17:05.357: RADIUS: 02 01 00 17 01 68 6F 73 74 2F 4C 61 62 47 6C 6F 62 61 6C 43 65 [host/LabGlobalCe]

128491: Feb 7 14:17:05.357: RADIUS: 72 74 [ rt]

128492: Feb 7 14:17:05.357: RADIUS: Message-Authenticato[80] 18

128493: Feb 7 14:17:05.357: RADIUS: 2B A0 68 84 36 8C 42 22 20 64 BE F4 CA A5 61 FD [ +h6B" da]

128494: Feb 7 14:17:05.357: RADIUS: EAP-Key-Name [102] 2 *

128495: Feb 7 14:17:05.357: RADIUS: Vendor, Cisco [26] 49

128496: Feb 7 14:17:05.357: RADIUS: Cisco AVpair [1] 43 "audit-session-id=0A640C41000001D11BACE0A2"

128497: Feb 7 14:17:05.357: RADIUS: NAS-Port-Type [61] 6 Virtual [5]

128498: Feb 7 14:17:05.357: RADIUS: NAS-Port [5] 6 1

128499: Feb 7 14:17:05.357: RADIUS: NAS-Port-Id [87] 9 "Wpan4/1"

128500: Feb 7 14:17:05.357: RADIUS: NAS-IP-Address [4] 6 10.100.12.65

Now when looking at ISE reply, I noticed it is using some random numbers for the EAP Identifier field:

030080: Feb 6 00:59:52.105: RADIUS: Received from id 1645/209 10.10.203.253:1812, Access-Challenge, len 122

030081: Feb 6 00:59:52.105: RADIUS: authenticator BC FD AE B6 4F 35 7D A5 - DA A7 85 E7 AA 7C 37 A8

030082: Feb 6 00:59:52.105: RADIUS: State [24] 76

030083: Feb 6 00:59:52.105: RADIUS: 33 37 43 50 4D 53 65 73 73 69 6F 6E 49 44 3D 30 [37CPMSessionID=0]

030084: Feb 6 00:59:52.105: RADIUS: 41 36 34 30 43 34 31 30 30 30 30 30 30 36 38 31 [A640C41000000681]

030085: Feb 6 00:59:52.105: RADIUS: 33 41 43 45 46 37 30 3B 33 31 53 65 73 73 69 6F [3ACEF70;31Sessio]

030086: Feb 6 00:59:52.105: RADIUS: 6E 49 44 3D 43 43 49 53 45 30 31 2F 33 30 36 38 [nID=CCISE01/3068]

030087: Feb 6 00:59:52.105: RADIUS: 30 38 37 33 31 2F 32 34 35 3B [ 08731/245;]

030088: Feb 6 00:59:52.105: RADIUS: EAP-Message [79] 8

030089: Feb 6 00:59:52.105: RADIUS: 01 FD 00 06 0D 20 [ ]

030090: Feb 6 00:59:52.105: RADIUS: Message-Authenticato[80] 18

030091: Feb 6 00:59:52.105: RADIUS: 9A 4E BE D3 5E FE 37 DC 5A 6F 8B EC 51 5F 33 96 [ N^7ZoQ_3]

030092: Feb 6 00:59:52.105: RADIUS(00000278): Received from id 1645/209

030093: Feb 6 00:59:52.107: RADIUS/DECODE: EAP-Message fragments, 6, total 6 bytes

…

030106: Feb 6 00:59:52.109: EAP code: 0x1 id: 0xFD length: 0x0006 type: 0xD

Other Radius server like NPS, CPAR or FreeRadius will instead increment the value of the Identifier of the previous request. It means for the packet captured above, a value of 0x2.

Why is ISE EAP implementation behaving differently from the other types of server ?

The reason I'm asking is my supplicant is expected the Identifier from a EAP-Request to be an increment of the previous one which means its is currently dropping the requests received from ISE.

Thanks for your support

hslai · ‎12-16-2018

I am not seeing any issue. Increment it sequentially is a suggestion.

rfc3748 4.1 Request and Response says,

...

Identifier
      ...
      In order to avoid confusion between new Requests and
      retransmissions, the Identifier value chosen for each new Request
      need only be different from the previous Request, but need not be
      unique within the conversation.  One way to achieve this is to
      start the Identifier at an initial value and increment it for each
      new Request.  Initializing the first Identifier with a random
      number rather than starting from zero is recommended, since it
      makes sequence attacks somewhat more difficult.
...

View solution in original post

hslai · ‎02-11-2018

We will discuss this further offline.

jharaldsson · ‎12-10-2018

Hi hslai,

I have also encountered this ISE EAP id issue.

Does the Cisco ISE EAP id implementation deviate from the RFC?

Thanks,

JH

hslai · ‎12-16-2018

I am not seeing any issue. Increment it sequentially is a suggestion.

rfc3748 4.1 Request and Response says,

...

Identifier
      ...
      In order to avoid confusion between new Requests and
      retransmissions, the Identifier value chosen for each new Request
      need only be different from the previous Request, but need not be
      unique within the conversation.  One way to achieve this is to
      start the Identifier at an initial value and increment it for each
      new Request.  Initializing the first Identifier with a random
      number rather than starting from zero is recommended, since it
      makes sequence attacks somewhat more difficult.
...

Titus O Neil · ‎10-13-2022

I tried to send CCX wifi packets but Cisco not recognize that. i guess maybe wrong format . I need Packet structure format .

Thanks.

Neil.