ISE 3.1 patch-1 and Radius PEAP GTC or PEAP MSCHAPv2

[adamscottmaster2013]

I have a Cisco ISE, version 3.1 patch-1, use for device administration with an IP address of 192.168.1.100. I have a client device (PaloAlto firewall) that has an IP address of 192.168.1.1.

I setup the PaloAlto for radius authentication via PEAP with GTC. I've enable PEAP with GTC on the ISE 3.1 patch-1. Everything is working fine but when I run tcpdump on the network, I still see the ISE respond back with the actual username in "clear text" over the wire. I thought PEAP MSCHAPv2 or PEAP with GTC is supposed to eliminate this.

Is this expected behavior?

Thoughts? See below

19:42:47.308821 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 88 [id 0] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.334877 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 154 [id 0] Attr[ [|radius] (DF)
19:42:47.335291 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 188 [id 1] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.337077 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 154 [id 1] Attr[ [|radius] (DF)
19:42:47.337553 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 389 [id 2] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.442931 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 1166 [id 2] Attr[ [|radius] (DF)
19:42:47.443537 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 188 [id 3] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.445595 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 1162 [id 3] Attr[ [|radius] (DF)
19:42:47.446096 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 188 [id 4] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.447489 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 281 [id 4] Attr[ [|radius] (DF)
19:42:47.459524 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 386 [id 5] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.475335 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 205 [id 5] Attr[ [|radius] (DF)
19:42:47.475866 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 188 [id 6] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.477807 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 184 [id 6] Attr[ [|radius] (DF)
19:42:47.478093 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 228 [id 7] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.479800 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 218 [id 7] Attr[ [|radius] (DF)
19:42:47.480137 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 223 [id 8] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.610645 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 194 [id 8] Attr[ [|radius] (DF)
19:42:47.611079 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 228 [id 9] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.627168 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-cha 194 [id 9] Attr[ [|radius] (DF)
19:42:47.627560 192.168.1.1.58251 > 192.168.1.100.1812: rad-access-req 232 [id 10] Attr[ User{anonymous} Framed_mtu{1200} Service_type{Framed} NAS_id{ACS} NAS_ipaddr{192.168.1.1} ]
19:42:47.637284 192.168.1.100.1812 > 192.168.1.1.58251: rad-access-accept 302 [id 10] Attr[ User{adamscott} [|radius] (DF)

[Arne Bier]

That's because the username is not being anonymised and the authenticator (switch or WLC) grabs the username from the EAP login and copies it into the RADIUS User-Name attribute. From there onwards it's reflected in clear text for all to see.

Some supplicants do allow anonymous outer authentication but I have not used it intentionally - Windows has an option called "Enable Identity Privacy". I have also seen it on WPA Supplicant software and other Linux/Android variants.  I would like to dive a bit deeper on this but that's about as much as I know off the cuff. 

Is hiding of usernames important?

The password is the thing that you don't want to see in cleartext. And with MSChapv2 there are no passwords - just exchanges of hashes.

[adamscottmaster2013]

---

@Arne Bier wrote:

That's because the username is not being anonymised and the authenticator (switch or WLC) grabs the username from the EAP login and copies it into the RADIUS User-Name attribute. From there onwards it's reflected in clear text for all to see.

Some supplicants do allow anonymous outer authentication but I have not used it intentionally - Windows has an option called "Enable Identity Privacy". I have also seen it on WPA Supplicant software and other Linux/Android variants.  I would like to dive a bit deeper on this but that's about as much as I know off the cuff. 

Is hiding of usernames important?

The password is the thing that you don't want to see in cleartext. And with MSChapv2 there are no passwords - just exchanges of hashes.

---

Yes.  Getting the username is winning half the battle.  You must not be working in security, LOL...

I don't know if you read the entire post before replying.  It is the ISE that sends back the username in cleartext.  The PaloAlto firewall anonymous username in the outer shell.  I enable feature on the PaloAlto firewall.  I am trying to understand the ISE is responding with sending username in cleartext over the wire, and that this is an expected behavior

[Arne Bier]

Hello @adamscottmaster2013 

You're entirely correct. I just performed EAP-PEAP MSCHAP-v2 with a Windows 10 client where the Identity Privacy was enabled.

I configured the Windows supplicant to use Identity Privacy (to obscure the outer identity) - I entered arbitrary text of "hideme300".

This is from a GNS3 lab ... I took some shortcuts on checking the ISE cert

I logged in as "user1" when prompted by the Windows Supplicant.

The ensuing wireshark on ISE shows that in the Access-Request contains User-Name "hideme300".

But as you pointed out, the final Access-Accept to the switch contains the inner identity of user1.

From a security point of view that is possibly not what you wanted. But. Consider that the NAS (WLC/Switch) usually takes that username in the Access-Accept for display purposes to show authenticated users. It's very helpful and also very helpful for troubleshooting. 

Perhaps there is an RFC somewhere that describes what SHOULD be sent in the final Access-Accept when identity privacy is used. If the RFC says that the User-Name MUST always be obfuscated, then I think you have a bone to pick with Cisco.

[thomas · Accepted solution]

ISE supports the RADIUS standard protocols s as documented in ISE Compatibility Guides.

If you find something where ISE is not compliant, please contact the Cisco TAC so they may file a bug.

Enable Identity Privacy in the Windows supplicant appears to be a Windows-ism and even Microsoft's NPS documentation states :

To configure your clients so that they will not send their identity in plaintext before the client has authenticated the RADIUS server, select Enable Identity Privacy , and then in Anonymous Identity , type a name or value, or leave the field empty.

[adamscottmaster2013]

The point I am trying to make here is that anytime you have "username" in "cleartext" over the wire, that is a very BAD idea.  That's what happen even you implement PEAP-GTC or PEAP-msCHAP-2.

[Arne Bier]

Hi @adamscottmaster2013 

Perhaps submit an enhancement request to Cisco to allow an option to preserve the original User-Name attribute in the final Access-Accept. I think in Freeradius you can do all these nice things (and perhaps in other commercial RADIUS products). ISE is not that flexible in this respect.

As for a security hazard? Yes of course in theory this could be an issue. But if you have a situation where a bad actor is already siphoning your RADIUS traffic and capturing usernames, then I think you're already in bad shape. Obscuring the username is most likely just a small hinderance to that bad actor. Strong passwords and MFA is potentially a better angle to look at this, since we can't always hide our identities since the reality is that a lot of companies use first.last@company.com as credentials - therefore we can already guess a username without needing to sniff the wire.